This is a post for my #100DaysOfCode Day 2 based on freeCodeCamp material I learned.
Websites should be open and accessible to everyone, regardles...
For further actions, you may consider blocking this person and/or reporting abuse
I'm really happy to see accessibility getting covered! It's a really important part of web development, and it's a foundational part of the web.
That being said, there's a couple of antipatterns in this article that need addressing:
The
.sr-onlyshould be updated to use properties that does not create mispronunciation when read by a screen reader.Interactive elements such as
a, andbuttondo not need atabindexapplied to them, as they can already receive keyboard focus. Additionally, usingtabindexvalues greater than0is discouraged, as it creates a tab order that differs from the natural document tab order. This can create a frustrating and disorienting experience for people who use assistive technology, as they may be prevented from navigating to an interactive element on the page, or be navigated to to one that they did not expect to follow next. The Paciello Group has written about this in more detail.I would also advise against using the
accesskeyattribute, as it is problematic for a variety of reasons.The other techniques presented are great things to be aware of, and I'm really enjoying having them all collected in one place like this.
+1 to Eric's comments, especially the mention of accessibility getting covered!
One other thing I'd love you to add to any
aelement: please be sure thosehrefattributes are not empty... that ensures that theawill be reachable by keyboard users.Thanks again for making a good list for beginners to accessibility.
Thank you for your comment Eric, I'm a beginner myself with this topic, I'll read the links carefully.
The golden rule of using [tabindex] is: never use values other than 0 and -1. Any other value changes the default focus order, creating unexpected experience for the user.
There is also issue with
[accesskey]as it's not usable across browsers. Nearly every browser has its own format for shortcuts. In most cases it's better to implement keyboard shortcuts with some scripting.Thank you for your comment Tomasz, I'll learn more about the topic.
Nice starter. A few things I'm missing are:
aria-labelfor descriptions that only screen readers should read out,aria-hiddento hide stuff from being read outbuttonfor any element that works as a button (even outside of a form) so the browser will translate keypresses of space or enter into click eventstabindex="0"will set the tabindex in the DOM element order after those elements with a tabindex higher than zeroThank you, Alex! I'll edit the post with this information.
I've never seen the accesskey attribute before, quite cool! How would you communicate to the user what accesskeys do what though?
aria-describedby on the body, linking to a (hidden until activated by non-visually-impaired user) list of keyboard shortcuts. Caveat: different browsers / OS will need different keys (see developer.mozilla.org/de/docs/Web/...), so either create the list with JS or prefix it with a short description.
You could also use [ALT]-[key] as a default and distinguish the browsers on Windows with different behavior ([ALT]-[SHIFT]-[key] on Firefox, [Shift]-[ESC] + [key] on Opera <= 12, or ignore this one as it is basically not used anymore nowadays) using CSS hacks and add a note about [CTRL]-[ALT]-[key] on Mac (and ignore Firefox prior to version 14, which used [CTRL]-[key] instead).
Wow that's really cool so it's like a key/legend that only visually impaired people will see
You can also let power-users "see" it when they activate it in a submenu. Accessibility is for everyone.
Yeah for web apps that would be ideal, no harm in displaying shortcuts for everyone. I'm sure Atlassian do this for a few of their tools.
One thing I do wonder though is how it would differ from just making sure your website is accessible via tabbing? or is it just a shortcut to stuff so you don't have to tab through the whole site to find what you are looking for
Yes, it is a shortcut to empower users who rely on keyboard only to use your application faster. That's accessibility: empowering users.
From a design perspective making sure your designs have enough contrast (especially text on a background) is often overlooked. From all the technical defaults (alt text etc. a developer can implement) we should also talk to designers about how they can make their designs more inclusive.
I've never really thought about accessibility before. Is there a good way for me to try experiencing a site from the perspective of an end user using a reader or something?
There are plenty of screen readers out there. One thing I do is to move around a page using the keyboard only. Start at the address bar, (or anywhere, really) and just see how far tabbing gets you!
Great article :)
Very useful guide to adding accessibility for your end users - something often overlooked!
Nice. Quick and easy. Tks
Awesome article Maria, thanks :)
Great guide. For those working on accessible websites I also highly recommend the WAVE evaluation extension for Chrome, I find it invaluable.