7 ms·

I'm currently evaluating a lot of CSS frameworks on how accessible they are (for an upcoming blog post), so I'd like to give it a go: 1. "Focus ring" (focus in

I'm currently evaluating a lot of CSS frameworks on how accessible they are (for an upcoming blog post), so I'd like to give it a go: 1. "Focus ring" (focus indicator) is completely missing for buttons. I cannot navigate the site with my keyboard if I don't see the currently focused element. Never remove the outline for focusable elements without providing a sufficient alternative. 2. The focus ring for the form elements is insufficient, especially for input fields. 3. The green, blue and red buttons have insufficient contrast ratio. Use something like [0] to find accessible color combinations. 4. Only native components are used (button, input) - that's great! This way, almost no ARIA is needed. Adding role="alert" [1] to the balloons is the only one I'm missing. 5. The mobile layout is broken for inputs. Unfortunately, many CSS frameworks either partially or fully ignore the accessibility aspect. It takes a lot of experience and time to make a website fully WCAG-compliant, but it's quite easy to follow some basic guidelines, like in this cheatsheet [2]. [0] https://contrast-ratio.com/ https://contrast-ratio.com/ [1] https://www.w3.org/TR/wai-aria-practices-1.1/#alert https://www.w3.org/TR/wai-aria-practices-1.1/#alert [2] https://moritzgiessmann.de/accessibility-cheatsheet/ https://moritzgiessmann.de/accessibility-cheatsheet/

dsamarin 8y ago
I've been considering evaluating the accessibility of my sites and I would like to see the impact of the changes I make with WAI-ARIA. Can I do this with a screen reader and are there FOSS or built-in screen readers you can recommend I test with?
- bambataa 8y ago
  Not the OP but you can do a lot with the following: - view your site in lynx - try and navigate around it with only your keyboard - try navigating around it using your OS' screen reader
- darekkay 8y ago
  There are free and built-in screen readers: NVDA[0] (Windows), VoiceOver[1] (Apple) and Orca[2] (Linux). I've been only working with NVDA so far. I highly recommend this NVDA Cheatsheet [3] to get a quick overview. It's also important to test NVDA with Firefox, as it has a better compatibility and thus it is the more common setup for users relying on a screen reader. Look into the difference between "Browse Mode" and "Focus Mode" (briefly explained in the cheatsheet) and how to switch between them. In the Focus Mode you can just tab through all of your focusable elements and check if the announced texts are understandable and no information is missing. In Browse Mode you go through all of the non-focusable content, and again, check if the output is clear and no (implicit) information is missing. This applies especially to all custom components which may announce gibberish if not handled correctly. Finally, you can look into my slides and examples for my "Accessible Web" talk [4]. [0] https://www.nvaccess.org/ https://www.nvaccess.org/ [1] https://www.apple.com/de/accessibility/mac/vision/ https://www.apple.com/de/accessibility/mac/vision/ [2] https://wiki.gnome.org/Projects/Orca https://wiki.gnome.org/Projects/Orca [3] https://dequeuniversity.com/screenreaders/nvda-keyboard-shortcuts https://dequeuniversity.com/screenreaders/nvda-keyboard-shor... [4] https://darekkay.github.io/presentations/ https://darekkay.github.io/presentations/
  - vanadium 8y ago
    Accessibility is one place where you'll invariably be forced to pay at some point because the 800lb gorilla of screenreaders (JAWS) is also what's used most often in both home and in most corporate environments. https://webaim.org/projects/screenreadersurvey7/ https://webaim.org/projects/screenreadersurvey7/
- kakarot 8y ago
  Also worth mentioning that Chrome has a built-in stripped-down screen reader in the developer tools which will display and allow you to navigate through your elements. It's worked well enough for me.
deleted 8y ago
[deleted]
kakarot 8y ago
I went down the ARIA rabbit hole this year. Christ almighty. It's understandable why anyone who isn't specifically specialized in this fucks it up. The documentation is arcane, redundant and lots of it is inapplicable. However, it was a fantastic learning experience, and integrating ARIA roles into my Mithril [0] components meant I only really had to implement some boilerplate once. It still took months of reading and I'm still far from an accessibility "expert" but I feel like a much better developer as a result. It's seriously staggering how many steps backwards we've taken in terms of accessibility with the advent of modern frameworks, which is why I was very happy that integrating ARIA into Mithril was a cinch. A lot of this stuff is supposed to come for free with modern browsers but JS templating engines completely destroy the expected state of the document, with the most prominent and immediate examples being the lack of handling live updates, keyboard navigation, and forms correctly. [0] https://mithril.js.org/ https://mithril.js.org/
- darekkay 8y ago
  > It's understandable why anyone who isn't specifically specialized in this fucks it up. The documentation is arcane, redundant and lots of it is inapplicable. I fully agree on the first sentence. For the last < 2 years, I was really fortunate to work on a project which is required by law to comply with WCAG 2.0. I've learned a lot, so I'm trying to share my lessons learned whenever I can. From my point of view, I cannot fully agree with your second sentence. If you know the basic WCAG and ARIA principles, the WAI-ARIA Authoring Practices is a highly useful and clear resource for implementing custom components. However, using this document without any prior experience will lead to the rabbit hole you described. We can definitely do better here, and fortunately accessibility has been gaining traction in the last few years.
  - kakarot 8y ago
    The thing is, the WAI-ARIA page works well as a reference, but not as an onboarding process. You have to develop your ARIA chops elsewhere and then come back to the document to learn the finer points of each role. And roughly half of the document will never be useful, and slightly more of it is overshadowed with native HTML5 tags. I updated my comment with a sample project with some very basic accessiblity and aria roles, if you feel like giving me some pointers or critique.
smacktoward 8y ago
Thank you for raising these issues, they are important and too often neglected.
sizzle 8y ago
Are there any automated accessibility checkers that catch the low hanging fruit?
- noicebrewery 8y ago
  https://squizlabs.github.io/HTML_CodeSniffer/ https://squizlabs.github.io/HTML_CodeSniffer/ I always liked this.
- darekkay 8y ago
  For low hanging fruits I would recommend using Lighthouse, which is integrated into Chrome (DevTools → Audit). That's what web.dev is also using [0]. Under the hood "axe-core" is being used. Another option is pa11y [1]. All three tools offer CI integration, but you still have to do some work to fully automate it. If you're using React / JSX, there is also an eslint plugin available [2]. [0] https://web.dev/ https://web.dev/ [1] http://pa11y.org/ http://pa11y.org/ [2] https://github.com/evcohen/eslint-plugin-jsx-a11y https://github.com/evcohen/eslint-plugin-jsx-a11y

dsamarin 8y ago

I've been considering evaluating the accessibility of my sites and I would like to see the impact of the changes I make with WAI-ARIA. Can I do this with a screen reader and are there FOSS or built-in screen readers you can recommend I test with?

bambataa 8y ago
Not the OP but you can do a lot with the following: - view your site in lynx - try and navigate around it with only your keyboard - try navigating around it using your OS' screen reader
darekkay 8y ago
There are free and built-in screen readers: NVDA[0] (Windows), VoiceOver[1] (Apple) and Orca[2] (Linux). I've been only working with NVDA so far. I highly recommend this NVDA Cheatsheet [3] to get a quick overview. It's also important to test NVDA with Firefox, as it has a better compatibility and thus it is the more common setup for users relying on a screen reader. Look into the difference between "Browse Mode" and "Focus Mode" (briefly explained in the cheatsheet) and how to switch between them. In the Focus Mode you can just tab through all of your focusable elements and check if the announced texts are understandable and no information is missing. In Browse Mode you go through all of the non-focusable content, and again, check if the output is clear and no (implicit) information is missing. This applies especially to all custom components which may announce gibberish if not handled correctly. Finally, you can look into my slides and examples for my "Accessible Web" talk [4]. [0] https://www.nvaccess.org/ https://www.nvaccess.org/ [1] https://www.apple.com/de/accessibility/mac/vision/ https://www.apple.com/de/accessibility/mac/vision/ [2] https://wiki.gnome.org/Projects/Orca https://wiki.gnome.org/Projects/Orca [3] https://dequeuniversity.com/screenreaders/nvda-keyboard-shortcuts https://dequeuniversity.com/screenreaders/nvda-keyboard-shor... [4] https://darekkay.github.io/presentations/ https://darekkay.github.io/presentations/
- vanadium 8y ago
  Accessibility is one place where you'll invariably be forced to pay at some point because the 800lb gorilla of screenreaders (JAWS) is also what's used most often in both home and in most corporate environments. https://webaim.org/projects/screenreadersurvey7/ https://webaim.org/projects/screenreadersurvey7/
kakarot 8y ago
Also worth mentioning that Chrome has a built-in stripped-down screen reader in the developer tools which will display and allow you to navigate through your elements. It's worked well enough for me.

deleted 8y ago

[deleted]

kakarot 8y ago

I went down the ARIA rabbit hole this year. Christ almighty. It's understandable why anyone who isn't specifically specialized in this fucks it up. The documentation is arcane, redundant and lots of it is inapplicable. However, it was a fantastic learning experience, and integrating ARIA roles into my Mithril [0] components meant I only really had to implement some boilerplate once. It still took months of reading and I'm still far from an accessibility "expert" but I feel like a much better developer as a result. It's seriously staggering how many steps backwards we've taken in terms of accessibility with the advent of modern frameworks, which is why I was very happy that integrating ARIA into Mithril was a cinch. A lot of this stuff is supposed to come for free with modern browsers but JS templating engines completely destroy the expected state of the document, with the most prominent and immediate examples being the lack of handling live updates, keyboard navigation, and forms correctly. [0] https://mithril.js.org/ https://mithril.js.org/

darekkay 8y ago
> It's understandable why anyone who isn't specifically specialized in this fucks it up. The documentation is arcane, redundant and lots of it is inapplicable. I fully agree on the first sentence. For the last < 2 years, I was really fortunate to work on a project which is required by law to comply with WCAG 2.0. I've learned a lot, so I'm trying to share my lessons learned whenever I can. From my point of view, I cannot fully agree with your second sentence. If you know the basic WCAG and ARIA principles, the WAI-ARIA Authoring Practices is a highly useful and clear resource for implementing custom components. However, using this document without any prior experience will lead to the rabbit hole you described. We can definitely do better here, and fortunately accessibility has been gaining traction in the last few years.
- kakarot 8y ago
  The thing is, the WAI-ARIA page works well as a reference, but not as an onboarding process. You have to develop your ARIA chops elsewhere and then come back to the document to learn the finer points of each role. And roughly half of the document will never be useful, and slightly more of it is overshadowed with native HTML5 tags. I updated my comment with a sample project with some very basic accessiblity and aria roles, if you feel like giving me some pointers or critique.

smacktoward 8y ago

Thank you for raising these issues, they are important and too often neglected.

sizzle 8y ago

Are there any automated accessibility checkers that catch the low hanging fruit?

noicebrewery 8y ago
https://squizlabs.github.io/HTML_CodeSniffer/ https://squizlabs.github.io/HTML_CodeSniffer/ I always liked this.
darekkay 8y ago
For low hanging fruits I would recommend using Lighthouse, which is integrated into Chrome (DevTools → Audit). That's what web.dev is also using [0]. Under the hood "axe-core" is being used. Another option is pa11y [1]. All three tools offer CI integration, but you still have to do some work to fully automate it. If you're using React / JSX, there is also an eslint plugin available [2]. [0] https://web.dev/ https://web.dev/ [1] http://pa11y.org/ http://pa11y.org/ [2] https://github.com/evcohen/eslint-plugin-jsx-a11y https://github.com/evcohen/eslint-plugin-jsx-a11y