- From: Marcos Villaseñor <villasenor.marcos@gmail.com>
- Date: Fri, 8 Mar 2024 03:14:02 +0000
- To: Adam Cooper <cooperad@bigpond.com>, 'Guy Hickling' <guy.hickling@gmail.com>, 'WAI Interest Group discussion list' <w3c-wai-ig@w3.org>
- Message-ID: <DU2P250MB0286CE21045B6850F27608FCF8272@DU2P250MB0286.EURP250.PROD.OUTLOOK.COM>
Sorry for my lack of knowledge, but this makes me think of an important usability question that I would like some input on, if someone would be kind to chip in. These pages do not have blocks of content where sighted keyboard users have to go through a lot of tabbing to get to direct functionality. In fact, tabbing once in the UK Drivers License example gets you straight to the radio group, which is both good (that’s the main objective of the form) and bad, since the first interactive element could be a home button in the logo, further explanation of the banner or the back button. I would never consider myself capable of conducting a true WCAG audit (though I’m, working to that) and I would still argue it is a fail of 2.4.1 a situation where there is no skip link or the the skip link using a screen reader doesn’t focus on the H1 (which in this case is also a field/group label, which has it’s own pitfalls). I fully understand that advanced screen reader users have multiple ways of moving through content and I have been amazed by how much faster screen reader users can fill a relatively well designed form (or do many other things) than myself just relying on keyboard focus or the mouse. In my mind, however, inclusive design means not catering for expert screen reader users, but for someone that is just coming to grips (or has never discovered the full extent) of what screen readers can do. To cut it short, using an example of a form with no true navigation and a starting with: * A logo to home (abandoning the form) * A banner with some info and perhaps a link to learn more or provide feedback * A back button that is more convenient than tabbing out of the page and into the browser chrome All of which repeat on every step of what could be dozens of steps (following the one thing per page model). In my mind the correct behaviour would be to add a skip link that allows both sighted keyboard users and screen reader users to skip all of that and get straight to the functionality of the form. On the first step, someone using a screen reader can just skip past the link and understand everything on screen and just use the skip link to skip move past repeating bits on the following steps. A sighted keyboard user can decide that it’s just faster to use the skip link to get to fill in the form, but still have the option to tab past that link and access all interactive elements (back to home, abandoning the form; using the banner link to understand the limitations of the service or proving feedback; going back one step). Is this correct or am I missing something? The reality is that organisations care very little about true inclusive design, but (for regulatory or other reasons) do take a step back where something might fail WCAG. I’ve been in countless situations where a WCAG failure is not super evident, but usability for assistive technology (or just not able-bodied click and tap) is terrible and arguing that is an ouright fail has made a huge difference on having product and engineering reconsider choices rather than just outright ignoring user experience for everyone that is not just like them. From: Adam Cooper <cooperad@bigpond.com> Date: Friday, 8 March 2024 at 02:00 To: 'Guy Hickling' <guy.hickling@gmail.com>, 'WAI Interest Group discussion list' <w3c-wai-ig@w3.org> Subject: RE: Skip to content link yes, I have always found it perplexing that skip to links in headers are hidden from the very users they are intended to benefit, but does that really mean they fail 2.4.1? likely, this is trampling ground already well walked, but there remains a mechanism after all even if it only becomes visible once focused? That is, there is enough wriggle room in the SC for this case to be conforming not to mention other such cases I listed below. And just what normatively constitutes a block anyway? More than two focusable elements? I read Jacob Neilsen’s post about thirty years of accessibility failures shared by Léonie Watson and scoff about generative AI, but ponder whether the gaps in WCAG and its inherent ambiguity are actually part of this failing … nearly 20 years of WCAG 2.x and we’re still debating the fundaments. From: Guy Hickling <guy.hickling@gmail.com> Sent: Friday, March 8, 2024 12:18 PM To: WAI Interest Group discussion list <w3c-wai-ig@w3.org> Subject: RE: Skip to content link Skip links aren't intended for screen reader users, though that may have been how they started in the very early days of the web. They are for sighted keyboard-only users, who have to navigate using only the tab key. Those users do not have any of the options offered by a screen reader. The "Skip to main content" link is specifically so that keyboard users do not have to tab all the way through the header (often 50 or 60 links and buttons on larger sites), otherwise those users have to tab through every link, on every page they go to. Which is also why all skip links must be visible when a user tabs onto them - they fail SC2.4.1 if they are not visible.
Received on Friday, 8 March 2024 03:14:10 UTC