- From: Adam Cooper <cooperad@bigpond.com>
- Date: Sun, 19 Oct 2025 09:11:21 +1100
- To: "'Ms J'" <ms.jflz.woop@gmail.com>, "'Tangen, Michael \(MNIT\)'" <Michael.Tangen@state.mn.us>, "'Mark Magennis'" <Mark.Magennis@skillsoft.com>, "'Steve Green'" <steve.green@testpartners.co.uk>, "'w3c-wai-ig'" <w3c-wai-ig@w3.org>
- Message-ID: <000e01dc407c$247a7600$6d6f6200$@bigpond.com>
Looks good … it might inadvertently capture other situations like when an image is positioned over a long tract of visually hidden text as a text alternative or even – in the minds of some people – things like aria-label? But - to play devil’s advocate for a second - is it really an access issue or merely about user experience? Can it really be argued that people who are sighted are prevented from completing this or that task because of hidden content? As someone who has been using a screen reader for twenty years , there are only a handful of cases in which hidden content may be of benefit. One such case is when skipping through a view using headings, I encounter a pagination widget with a hidden headings .. but it’s only convenient because I have been navigating using headings already. But cases in which text like ‘end of section’ or ‘start of dialog’ or nonsensical explanations occur floating in the middle of a view are irritating because they both add to verbosity unnecessarily and demonstrate a naivety on the part of the implementer. I personally don’t use cursor keys for coarse navigation, but, believe it or not, some people using a screen reader do … entire views using nothing but arrow keys! Many people on this basis might say ‘we need hidden content in addition to every other form of screen reader specific content to make it accessible’, but this is the wrong approach … what people using screen readers need is consistent and conventional implementations upon which they can easily discover, remember, and rely upon to make navigating and operating a user interface effective, efficient, and frictionless. From: Ms J <ms.jflz.woop@gmail.com> Sent: Sunday, October 19, 2025 1:23 AM To: Adam Cooper <cooperad@bigpond.com>; 'Tangen, Michael (MNIT)' <Michael.Tangen@state.mn.us>; 'Mark Magennis' <Mark.Magennis@skillsoft.com>; 'Steve Green' <steve.green@testpartners.co.uk>; 'w3c-wai-ig' <w3c-wai-ig@w3.org> Subject: Re: [EXTERNAL] Re: Unnecessary visually hidden text or, rather, 'If content is visually hidden, this implies that it is unnecessary and removing it will improve the user experience for sighted users. Therefore, if such content has no visual equivalent that it is acting as an alternative to, it may also benefit screen reader users hide it from them too.' ? Sarah Sent from Outlook for iOS <https://aka.ms/o0ukef> _____ From: Adam Cooper <cooperad@bigpond.com <mailto:cooperad@bigpond.com> > Sent: Saturday, October 18, 2025 12:03:37 AM To: 'Ms J' <ms.jflz.woop@gmail.com <mailto:ms.jflz.woop@gmail.com> >; 'Tangen, Michael (MNIT)' <Michael.Tangen@state.mn.us <mailto:Michael.Tangen@state.mn.us> >; 'Mark Magennis' <Mark.Magennis@skillsoft.com <mailto:Mark.Magennis@skillsoft.com> >; 'Steve Green' <steve.green@testpartners.co.uk <mailto:steve.green@testpartners.co.uk> >; 'w3c-wai-ig' <w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> > Subject: RE: [EXTERNAL] Re: Unnecessary visually hidden text I’d say that the radio button example is a stretched interpretation of ‘equivalent’ in 1.1.1, but still not seeing (no pun intended) the failure of 1.3.1 … The “rendering of the content in a form to be perceived by users” is wiggly enough for it to say be perceived by any person including by someone using a screen reader by my way of thinking, but – if 1.3.1 works for you – knock yourself out! I definitely agree with the spirit of what you’re saying, but perhaps not the letter …. This is again one of those items that needs to be picked up in that currently hot mess of WCAG 3.0? Guideline x.x Foundational requirement: well meaning implementer ignorance * Content is not hidden from sighted users because your implementation is rubbish and you believe – without ever asking a screen reader user – that hidden text would benefit screen reader users. Or something like that? From: Ms J <ms.jflz.woop@gmail.com <mailto:ms.jflz.woop@gmail.com> > Sent: Friday, October 17, 2025 7:41 PM To: Adam Cooper <cooperad@bigpond.com <mailto:cooperad@bigpond.com> >; 'Tangen, Michael (MNIT)' <Michael.Tangen@state.mn.us <mailto:Michael.Tangen@state.mn.us> >; 'Mark Magennis' <Mark.Magennis@skillsoft.com <mailto:Mark.Magennis@skillsoft.com> >; 'Steve Green' <steve.green@testpartners.co.uk <mailto:steve.green@testpartners.co.uk> >; 'w3c-wai-ig' <w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> > Subject: Re: [EXTERNAL] Re: Unnecessary visually hidden text Hi Adam Couldn’t agree more - especially with your feelings on the use of ‘confused’! This is something we are mindful of where I work. It is a lazy way to describe an issue, and it reads so condescendingly: describing in issue in terms of the actual issue aka ’the heading structure was not reflected in the mark up which means screen reader users will not be presented the structure of the information’ is so much clearer than ’the heading structure was not reflected in the mark up which means screen reader users will be confused’. The word ‘confused’ really undermines the impact of an issue too because it narrows the real issue - screen reader users do not have access to the information or functionality that other users do - to one single basic emotional interpretation of how that may feel - confusion - which is trivialising - there are a tonne of negative consequences to content not being accessible, not just ‘confusion''. However, where the users themselves describe feeling ‘confused’, I do usually pass this feedback on. The reason I feel like 1.3.1 may accommodate it is that if they are intending to hide information that is not hidden from all users, because they haven’t used display; none; so it is still exposed to screen reader software, then I would say that is covered by 1.3.1 - hide it for everyone… so at the point at which visually hidden text is not an alternative for some visual information, could we possibly argue - well then you have hidden it from some (because let's face it, you have deemed it less than optimal), so extend this courtesy by hiding it from screen reader users too… the example of radio buttons with ‘answer 1’ and ‘answer 2’ at the start of the accessible name for example - it is tricky to argue why this is fundamentally ‘wrong’… except they have hidden it visually and they have clearly done that for a reason… it isn’t the alternative to some visual information, so at that point surely it’s fair enough to say ‘hide for one, hide for all’? Sarah From: Adam Cooper <cooperad@bigpond.com <mailto:cooperad@bigpond.com> > Date: Friday, 17 October 2025 at 02:32 To: 'Ms J' <ms.jflz.woop@gmail.com <mailto:ms.jflz.woop@gmail.com> >, 'Tangen, Michael (MNIT)' <Michael.Tangen@state.mn.us <mailto:Michael.Tangen@state.mn.us> >, 'Mark Magennis' <Mark.Magennis@skillsoft.com <mailto:Mark.Magennis@skillsoft.com> >, 'Steve Green' <steve.green@testpartners.co.uk <mailto:steve.green@testpartners.co.uk> >, 'w3c-wai-ig' <w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> > Subject: RE: [EXTERNAL] Re: Unnecessary visually hidden text Semantic markup isn’t the be-all-and-end-all of conveying supplementary information like hierarchies or relationships between items because: 1. Implementers don’t understand the purpose of semantic markup and what information It is capable (or not) of conveying … definition/description lists, for example 2. Structural markup is used willy-nilly like it’s 2001 and we’re still supporting IE4 … a single bullet point below a heading, for example 3. Myths in the designer and implementer community about certain types of markup … not using tables for name-value pairs, for example, because people believe tat screen reader users don’t like/can’t navigate tables 4. Misunderstandings about fall-back or so-called graceful degradation … menus constructed of endless nested lists navigate by TAB or mouse hover – I defy anyone to try and navigate these using a screen reader all-the-while remembering where you are. 5. User agent support is incomplete and/or inconsistent The set of meanings conveyed by structural markup in HTML is VERY limited and screen reader support for these features is patchy (definition/description lists, for example) However, this is not licence to stuff screen reader only content all over the place lest screen reader users are ‘confused’ by what they encounter. I find the use of ‘confusion’ as a rationale for any feature EXTREMELY patronising as if losing one’s vision accordantly means someone is similarly cognitively impaired. If something requires ‘visually hidden content for screen reader users’, then it is either pandering to a preference or is just badly designed plain and simple. Hidden headings is a great example, but one practice which thankfully seems to be fading. What is required is a definition of the semantics of structural markup (the HTML specification is far too vague on this) and how and when to use these semantics. Unfortunately, though unless we’re willing to stretch the creaking normative definitions in WCAG 2.x to breaking point, then I can’t see a success criterion under which visually hidden or screen-reader only content can be failed. From: Ms J <ms.jflz.woop@gmail.com <mailto:ms.jflz.woop@gmail.com> > Sent: Friday, October 17, 2025 12:25 AM To: Tangen, Michael (MNIT) <Michael.Tangen@state.mn.us <mailto:Michael.Tangen@state.mn.us> >; Mark Magennis <Mark.Magennis@skillsoft.com <mailto:Mark.Magennis@skillsoft.com> >; Steve Green <steve.green@testpartners.co.uk <mailto:steve.green@testpartners.co.uk> >; 'w3c-wai-ig' <w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> > Subject: Re: [EXTERNAL] Re: Unnecessary visually hidden text Yes Michael, you are correct in your understanding of semantic HTML. Ideally, semantic mark-up would be used wherever possible - however sometimes where it is not possible, devs use text and visually hide it using CSS. However, sometimes they add information that is unclear or ambiguous that does not reflect any information that is conveyed visually. Sarah Sent from Outlook for iOS <https://aka.ms/o0ukef> _____ From: Tangen, Michael (MNIT) <Michael.Tangen@state.mn.us <mailto:Michael.Tangen@state.mn.us> > Sent: Thursday, October 16, 2025 2:09:21 PM To: Mark Magennis <Mark.Magennis@skillsoft.com <mailto:Mark.Magennis@skillsoft.com> >; Ms J <ms.jflz.woop@gmail.com <mailto:ms.jflz.woop@gmail.com> >; Steve Green <steve.green@testpartners.co.uk <mailto:steve.green@testpartners.co.uk> >; 'w3c-wai-ig' <w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> > Subject: Re: [EXTERNAL] Re: Unnecessary visually hidden text On thing that may help if you have no experience actually working in assistive technology (such as JAWS, Voiceover for Mac, etc) is that tags that have semantic meaning inherent in them (such as <li> <h1> <input>) and imply that it has some sort of specific role or function (as opposed to <div> and <span> which bear no meaning whatsoever), the assistive technology is more likely to convey to the user that meaning. So if a user tabs into a form control, such as an input tag, it's going to convey that as much; or if they are in an ordered list, it's likely to convey what numbered list item is being presented to them in that moment. Michael Tangen Sr. Interface Designer & Developer | Application Development for Web/mn.gov Pronouns: he/he hoooooo <https://youtu.be/siLkbdVxntU> Find helpful information on managing your Tridion-based website at mn.gov/showcase/ <https://mn.gov/showcase/> Need a demo on Formstack or advice on HTML/CSS in Tridion? Book a 30-minute session <https://outlook.office.com/bookwithme/user/9c002b52477d4c55a8fb109cabbf282c%40state.mn.us?anonymous&ismsaljsauthenabled=true> with me. Minnesota IT Services | Partners in Performance Information Technology for Minnesota Government | <http://mn.gov/mnit> mn.gov/mnit _____ From: Mark Magennis <Mark.Magennis@skillsoft.com <mailto:Mark.Magennis@skillsoft.com> > Sent: Thursday, October 16, 2025 8:00 AM To: Ms J <ms.jflz.woop@gmail.com <mailto:ms.jflz.woop@gmail.com> >; Steve Green <steve.green@testpartners.co.uk <mailto:steve.green@testpartners.co.uk> >; 'w3c-wai-ig' <w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> > Subject: Re: [EXTERNAL] Re: Unnecessary visually hidden text This message may be from an external email source. Do not select links or open attachments unless verified. Report all suspicious emails to Minnesota IT Services Security Operations Center. _____ So basically what you're saying is that adding stuff that's unnecessary and confusing is bad. Yep, I agree with that. I think it often comes from a lack of understanding of the experiences that screen reader users have on websites, not knowing what they therefore need, and throwing everything at it just to be safe. Mark _____ From: Ms J <ms.jflz.woop@gmail.com <mailto:ms.jflz.woop@gmail.com> > Sent: Thursday, October 16, 2025 12:39 To: Steve Green <steve.green@testpartners.co.uk <mailto:steve.green@testpartners.co.uk> >; 'w3c-wai-ig' <w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> > Subject: [EXTERNAL] Re: Unnecessary visually hidden text Hi Steve Thanks just to clarify, this is not me questioning the use of visually hidden text where it IS the alternative to information a screen reader may use. This is where it is used and it is NOT helpful or useful and users report that is was confusing. What I'm talking about is, for example, visually hidden headings before a question on a test saying 'question'. Extra text in a label for a radio button saying 'answer 1, answer 2, answer 3' even though they aren't numbered visually and you can infer order with a screen reader in the same way you would read it visually... given text before a radio group saying 'radio group' even though it is marked up as a radio group... questions duplicated 3 times as, for example, a single field being marked up in a group with a visually hidden legend (repeating the field label) and then it being there in text and then as the aria-label... Thanks Sarah Sent from Outlook for iOS <https://aka.ms/o0ukef> _____ From: Steve Green <steve.green@testpartners.co.uk <mailto:steve.green@testpartners.co.uk> > Sent: Thursday, October 16, 2025 12:29:44 PM To: Ms J <ms.jflz.woop@gmail.com <mailto:ms.jflz.woop@gmail.com> >; 'w3c-wai-ig' <w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> > Subject: RE: Unnecessary visually hidden text I often encounter content that requires an explanation for people who can’t see it. Sometimes that’s because an area of content makes sense when viewed as a whole, but it would be difficult or impossible for a screen reader user to understand it when they encounter it one piece at a time. In other cases, content needs explanation because HTML doesn’t have the necessary elements and attributes to convey the purpose and behaviour programmatically. Then there are scenarios in which form controls cause page content to change without a page reload. For a sighted person, it’s obvious what has happened, but a screen reader user would not be aware that anything had happened if instructions had not been provided. Sometimes, a live region can convey sufficient information, but other times it’s best to provide instructions that can be read before the user interacts with the page. In my view, “universal design” is a myth, and there isn’t one design that will be suitable for everyone. Obviously, we want to get as close to that as possible, but sometimes you do need to provide additional information or features (or maybe remove some) for people with specific needs. Steve Green Managing Director Test Partners Ltd From: Ms J <ms.jflz.woop@gmail.com <mailto:ms.jflz.woop@gmail.com> > Sent: 16 October 2025 12:10 To: 'w3c-wai-ig' <w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> > Subject: Unnecessary visually hidden text Hello I have noticed many web content authors using a screen reader only class to add visually hidden text which is not conveying information otherwise displayed visually. I think this is well meaning and just comes from not really understanding what information users really need. However, the result is that it ends up benefiting sighted users by tidying up the page visually so it is succinct and direct, whilst leaving information deemed as clearly unhelpful enough to hide there for screen reader users. I also think it's somewhat condescending - if you are blind then you need an alternative to any information that is conveyed visually, but you don't need anything else spelled out any more than any other standard user. I am wondering if anyone else has encountered this and how they handle it please? My feeling is that information should surely only be visually hidden if it is clearly there in another form visually. Otherwise, if it is not an alternative to information there visually in another format, and an author would not want to publish the page with it there visually because it looks unprofessional or unnecessary, then they should remove it, so the page presented just as professionally to users reading it via a screen reader. I am interested to hear other people's views on this? Thanks Sarah Sent from Outlook for iOS <https://aka.ms/o0ukef>
Attachments
- image/png attachment: image001.png
Received on Saturday, 18 October 2025 22:11:34 UTC