What WCAG rules fails if Screen Reader focus is going on hidden text which is either incorrect or redundant when user is navigating in scan/browser mode

[rahulpundir019]

I found a issue where Screen Reader focus is going on hidden text which is either incorrect or redundant when user is navigating in scan/browser mode.

When I am trying to map this issue in WCAG, I am not able to find any appropriate guideline.

Closest guidelines are Meaningful Sequence, Name role value and Info & Relationships but need second opinion?

[GreggVan]

I think that it should be part of 1.3.1 and say that everything visible needs to be programmatically accessible, and everything that is not visible, should not be programmatically accessible, or should be marked clearly as non-visual at this time. But I really think it should be not programmatically accessible at all. Otherwise, a page that uses expanding paragraphs would be very usable by someone with vision, but unusable by someone who was using a screen reader because it would read everything not just the expanded topics which could mean a 200 or 300 page document with collapsing paragraphs would be one or two pages for someone who sees but two or 300 pages for someone using a screen reader. We don't say this explicitly, but we should either put it as a note or put it in understanding as this. And in. WCAG3 we need something specific.

[SaraSoueidan]

Wouldn't that mean that all visually-hidden text would fail the SC—including purposeful visually-hidden text?

[rahulpundir019]

I think if it is purposefully hidden, that makes sense not to fail, as there is no user impact as such(like the common case I observed is that the dev hides status message for Screen Reader users, where that status message is not visible to all users, as it is obvious to them)

[mraccess77]

In many situations hidden text that is available to screen readers could fail SC 1.3.1. However, there are some situations where this is useful and likely would not fail SC 1.3.1 in my opinion if there is a valid use.

Regarding programmatic access discussion raised by Gregg. It's not uncommon to have truncation with large text on mobile or with cards that have a ... and expand. In these situations it can be beneficial to have the screen reader speak the full control label or the extra few words on the card without requiring the user to expand the card. Part of the challenge with truncated cards is that when the card text is expanded it's not really possible to set screen reader focus to the new first word that appeared and so it's difficult for screen reader users to find where they left off.

Another example, is partial text which gives you a visual clue that more content is to the left or right - this text may need some marking like aria-hidden to communicate it's not meant for active use - but it may still be useful to have it available programmatically for people who want to use point text to speech such as what comes with magnification software.

[rahulpundir019]

@mraccess77 @GreggVan @patrickhlauke Thanks yeah, I also think the closest is 1.3.1(or need a new one as it does not align with the current definition), but since it is NOT mentioned clearly in WCAG, so is there something we can do about it to add this case in WCAG? as I am new here, so not sure what the process is.

[patrickhlauke]

understanding documents/techniques are, by necessity, not comprehensive ... they can't cover every possible scenario out there in the wild wonderful web. having said that, this may be a common-enough situation that it might warrant a tiny example/mention somewhere...

[GreggVan]

Screen reader focus -- is an internal function of an Assistive technology - and is completely out of scope for WCAG. So no part of WCAG fails due to behavior of any AT.

However there are many SC that fail do to information not being made programmatically determinable by AT. What happens after that is up to the AT and out of scope for WCAG.

[rahulpundir019]

Totally understand the point you are making but in this case it is more of code issue than AT as I can see in the code that they have some text which is visually hidden so if it's irrelevant, it should also not be in screen reader reading order.

[detlevhfischer]

the thing that is affected is programmatic reading order, so we would cover cases where the inclusion of invisible things confuses or dilates that reading order in 1.3.2, and possibly also in 2.4.3 Focus order if invisible user interface elements receive focus.

[patrickhlauke]

strongest candidate for me is usually 1.3.1 info and relationships, as visually hiding content when it's not meant to be "active" (say, a warning message that is only meant to dynamically appear when the warning is needed, or "read more" type content that is only meant to show when the user actively toggles a "read more" button) to me counts as breaking the "Information, structure, and relationships conveyed through presentation" clause: the fact that presentation-wise, visually, it's hidden conveys the fact that it's not meant to be seen/perceived/announced.

this can then also cause 1.3.2 meaningful sequence issues.

and yes, of course if things are then ALSO keyboard-focusable when they're supposed to be hidden/inactive, that's a problem of 2.4.3 focus order too (and then maybe also 2.4.7 focus visible, 2.4.11 focus not obscured (minimum), etc ... but that's less ambiguous to determine

[GreggVan]

+1 to interpreting that things "that are invisible but are visible to AT" is just as much a failure as "things that are visible but not visible to AT". The two must match. If we don't have a specific failure documented for this -- we should add one to all of the relevant SCs including (but not necessarily limited to) 1.3.1 , 1.3.2, 2.4.3, 2.4.7, and 2.4.11