3 ms·

> 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.

> 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.
- darekkay 8y ago
  Is there a live component showcase for your project? Just from the source code I see some requirements [0] not being followed: * The element with role button has aria-haspopup set to either menu or true. * When the menu is displayed, the element with role button has aria-expanded set to true. When the menu is hidden, it is recommended that aria-expanded is not present. If aria-expanded is specified when the menu is hidden, it is set to false. I'd also use a native "button" instead of "div role=button". It's cumbersome to (un)style buttons, but you lose a lot of built-in functionality with a custom component, which you need to care for. [0] https://www.w3.org/TR/wai-aria-practices-1.1/#menubutton https://www.w3.org/TR/wai-aria-practices-1.1/#menubutton
  - kakarot 8y ago
    Not right now because I'm in the middle of integrating ansible into my servers and was waiting to get that finished, and I also need to make some changes with local storage. Nice catch on aria-haspopup! I totally missed that. Also good tip on aria-expanded, thank you. I can't remember why I went with a div instead of a button. I'd like to think there was a reason, but it was probably just oversight on my part. I appreciate your feedback!
- steveklabnik 8y ago
  I would like to second this in some sense. I would love to learn more about WAI-ARIA, but have no idea how to go about doing so. More non-reference documentation would be fantastic, or surfacing whatever does exist better.
vanadium 8y ago
I definitely know this pain (and glory) from experience and can relate. It all began when Ontario started enforcing AODA and the brand I was working with at the time had to be compliant due to their business operating in the province despite primarily being a U.S. company. I've done enterprise-level a11y projects for major brands, and the problem isn't always understanding the WCAG Success Criteria or WAI-ARIA, it's the _how_ that gets you. Multiple times, I literally had IBM's a11y practice and that of another major accessibility vendor (both of whom were hired for validation of approach and certification of the product coming from my team) disagreeing on which UX direction actually fulfilled the Success Criteria. The grey area of accessibility integration is _vast_ and in many cases, outright subjective. Oftentimes folks believe that just because you plunked ARIA roles and other a11y-specific best practices into a framework or design system, it actually works out to be a11y-compliant. While it gets you closer to the endgame, the complexity of the actual User Experience (e.g., running it through screen readers and other assistive devices, and not relying solely on static analysis like aXe or pa11y) is where the magic (and pain) actually happens. Accessible responsive patterns, contrast ratios, UX metaphors, affordances, etc.; all of that is yet another level of abstraction that'll keep a team with work for a very long time. (For those that really specialize in a11y to the point of becoming a consultant, though, it's a very lucrative career path for the above reasons.)

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.

darekkay 8y ago
Is there a live component showcase for your project? Just from the source code I see some requirements [0] not being followed: * The element with role button has aria-haspopup set to either menu or true. * When the menu is displayed, the element with role button has aria-expanded set to true. When the menu is hidden, it is recommended that aria-expanded is not present. If aria-expanded is specified when the menu is hidden, it is set to false. I'd also use a native "button" instead of "div role=button". It's cumbersome to (un)style buttons, but you lose a lot of built-in functionality with a custom component, which you need to care for. [0] https://www.w3.org/TR/wai-aria-practices-1.1/#menubutton https://www.w3.org/TR/wai-aria-practices-1.1/#menubutton
- kakarot 8y ago
  Not right now because I'm in the middle of integrating ansible into my servers and was waiting to get that finished, and I also need to make some changes with local storage. Nice catch on aria-haspopup! I totally missed that. Also good tip on aria-expanded, thank you. I can't remember why I went with a div instead of a button. I'd like to think there was a reason, but it was probably just oversight on my part. I appreciate your feedback!
steveklabnik 8y ago
I would like to second this in some sense. I would love to learn more about WAI-ARIA, but have no idea how to go about doing so. More non-reference documentation would be fantastic, or surfacing whatever does exist better.

vanadium 8y ago

I definitely know this pain (and glory) from experience and can relate. It all began when Ontario started enforcing AODA and the brand I was working with at the time had to be compliant due to their business operating in the province despite primarily being a U.S. company. I've done enterprise-level a11y projects for major brands, and the problem isn't always understanding the WCAG Success Criteria or WAI-ARIA, it's the _how_ that gets you. Multiple times, I literally had IBM's a11y practice and that of another major accessibility vendor (both of whom were hired for validation of approach and certification of the product coming from my team) disagreeing on which UX direction actually fulfilled the Success Criteria. The grey area of accessibility integration is _vast_ and in many cases, outright subjective. Oftentimes folks believe that just because you plunked ARIA roles and other a11y-specific best practices into a framework or design system, it actually works out to be a11y-compliant. While it gets you closer to the endgame, the complexity of the actual User Experience (e.g., running it through screen readers and other assistive devices, and not relying solely on static analysis like aXe or pa11y) is where the magic (and pain) actually happens. Accessible responsive patterns, contrast ratios, UX metaphors, affordances, etc.; all of that is yet another level of abstraction that'll keep a team with work for a very long time. (For those that really specialize in a11y to the point of becoming a consultant, though, it's a very lucrative career path for the above reasons.)