Does 1.3.1 apply to off screen content?

[WilcoFiers]

This topic came up during review of the Headers attribute specified on a cell refers to cells in the same table element
ACT Rule. Specifically around inapplicable example 3. SC 1.3.1 states:

Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text

The ACT Task Force has taken the phrase "conveyed through presentation" to mean that off-screen content (content available to assistive technologies, but positioned outside the viewport) is not applicable to 1.3.1. So for example, an off-screen heading is not required to have heading markup by 1.3.1. Or in a more extreme example, if an entire table is positioned off screen with no mechanism to reveal it (for whatever reason), SC 1.3.1 does not require association between table data and header cells.

This seems like a bit of a gap in WCAG 2, coming from the fact that WCAG requires all presentational info must be available programmatically (or in text), but not that all programmatic info must be available through presentation.

[patrickhlauke]

indeed, 1.3.1 nominally is only about the presentation, and built on the assumption that authors will generally visually style something a certain way, and not convey semantics. which then leaves open the whole "what if the headings have the same styling as regular text...does a site fail in that case?" and the inverse of 1.3.1, "does a site fail if the presentation doesn't convey semantics from the underlying markup".

in general, speaking purely for myself and the few places i've worked at doing audits, i take 1.3.1 to be about the "intrinsic" semantics of something and whether they're exposed, regardless of whether or not the presentation itself also conveys this. so i'd fail a heading not being marked up as a heading, even if visually it looks the same as regular text, for instance.

as for visually hidden content, i'd likewise pass/fail based on what the content intrinsically represents, rather than excluding it because it's not visible.

[WilcoFiers]

I think that's how most of us test it Patrick. That's generally how I prefer to think of this too, but I strictly speaking that's not really what the SC says to do I think. The only reason I can really justify failing something like paragraph text having heading markup is that it mucks up the heading structure of the page. I.e. the "presented heading structure" doesn't match the "programmatic heading structure". That more difficult to argue when it comes to things that aren't part of "page structure". For example I've seen people mark addresses up as lists, and then hide the bullets. I tend to be fairly permissive of things like that precisely because 1.3.1 doesn't say that every programmatic relationships has to be presented in some way.

[bruce-usab]

i'd fail a heading not being marked up as a heading, even if visually it looks the same as regular text, for instance.

Agreed, me too.

What if the headings have the same styling as regular text?

That is probably fine, and I would argue its a mistake to fail against 1.3.1. The concept of a heading is somewhat abstract. Consider the pattern of (1) a stand-alone sentence, (2) then several paragraphs, (3) repeat. Those stand-alone sentences being an H which uses the same styling as regular text is okay. The author probably has a reason for not making them stand out, but the white space still helps visual organization and scanning. The non-visual person using AT needs something comparable.

I tend to be fairly permissive of things like that precisely because...

Also agreed. The person using screen reading software is likely to notice that the address is a list. Unless it interferes with usability, I might not even flag it as a caution.

To OP question. I agree with the example, off-screen header-like text, being out of scope for 1.3.1. The off-screen data table makes me a little more cautious, but I the logic holds. Even with an off-screen data table, it seems to me that cell headers would be necessary, but I allow that the functionality could be provided elsewhere.

[alastc]

If the content is never visually rendered I'd agree it isn't covered by 1.3.1.

Most of the examples above (hidden headings / tables) tend to be added to make something accessible, so I'm not sure it's a concerning gap? Obviously people can get things wrong, but generally you need a bit of knowledge to know it is something you should add...

On the related topic of:

i'd fail a heading not being marked up as a heading, even if visually it looks the same as regular text, for instance.

I would guess that it is stand alone text above a section of content then? In which case you could argue there is some presentational aspect going on... If there isn't anything, how do you know it's a heading?

[detlevhfischer]

@WilcoFiers I would think that semantic content that is programmatically available, even if not visible in the viewport, should fall under rules like the one referenced above for headers mark-up - same for headings. I feel that visually hidden headings that are used to structire sections, while outdated, should appear in user's headings listings and exposed by SR shortcuts.

Proposed Working Group answer:
Content with intrinsic semantics, even if not visible in the viewport, should use the mark-up appropriate for that content. For example, invisible headings of content sections should be marked up as headings at the appropriate level so they appear, for example, in screen reader headings listings and are by exposed by screen reader shortcuts. Invisible data tables used as alternate version of data charts for users without vision should for the same reason have proper table mark-up so that header cells can be identified.

The ACT rule example referenced at the befinning of this issue can perhaps be remedied by changing:

This rule applies to any headers attribute specified on a cell within a table element, where the table element is visible and included in the accessibility tree.

to

This rule applies to any headers attribute specified on a cell within a table element, where the table element is included in the accessibility tree.

[alastc]

At the meeting we agreed to make this into an understanding document update: https://www.w3.org/2023/06/06-ag-minutes.html#t07

[pbossley]

My take on applying this to off screen content is that it is clearly not what the normative text of the SC says. We really should stick to words meaning things and if we think we need to make a change, write a new SC around that. I realize that takes time and effort but in my view it causes a real credibility issue for us to try to stretch to interpret an SC so clearly outside what it says.

[electrickite]

In the case of "an entire table is positioned off screen with no mechanism to reveal it (for whatever reason), SC 1.3.1 does not require association between table data and header cells", 1.3.1 does not seem to apply directly. However, if the off screen table is being used as an accessible alternative (to a visual chart, for example) it would likely fail other success criteria. Would an off screen table with improper structure fail meaningful sequence, for example, because there is no practical way for the heading text to be placed in sequence with the table cell content?