5 ms·

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 document

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.
  - 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.)
simplify 8y ago
Mithril's simplicity is a breath of fresh air compared to React's complexity. Highly recommend.
- kakarot 8y ago
  Learning React was a giant PITA. So many gotchas, so much boiler plate, plus it's not just React you're learning. You're learning React-Router, Flux/Redux plus half a dozen other tools each with their own verbose way of getting simple things done. Not only can you start developing meaningful Mithril components within an hour of reading documentation, you can more or less become an expert in a week or two. The only things that ever snagged me for considerable time always turned out to be Chrome bugs. And routing is so simple! I remember getting caught up for a while figuring out how to simplify authentication routing in React in a more DRY manner than what the docs recommended. This is what I came up with using Mithril's built-in router. Dead simple, yet expressive, and it supports dynamic imports as well as decoupling the path name from the routing method: https://github.com/soulofmischief/feathers-mithril-webpack-pwa-starter/blob/master/client/router/routes/index.js https://github.com/soulofmischief/feathers-mithril-webpack-p... https://github.com/soulofmischief/feathers-mithril-webpack-pwa-starter/blob/master/client/router/routes/Home.js https://github.com/soulofmischief/feathers-mithril-webpack-p... https://github.com/soulofmischief/feathers-mithril-webpack-pwa-starter/blob/master/client/lib/feathers/auth.js https://github.com/soulofmischief/feathers-mithril-webpack-p...

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

simplify 8y ago

Mithril's simplicity is a breath of fresh air compared to React's complexity. Highly recommend.

kakarot 8y ago
Learning React was a giant PITA. So many gotchas, so much boiler plate, plus it's not just React you're learning. You're learning React-Router, Flux/Redux plus half a dozen other tools each with their own verbose way of getting simple things done. Not only can you start developing meaningful Mithril components within an hour of reading documentation, you can more or less become an expert in a week or two. The only things that ever snagged me for considerable time always turned out to be Chrome bugs. And routing is so simple! I remember getting caught up for a while figuring out how to simplify authentication routing in React in a more DRY manner than what the docs recommended. This is what I came up with using Mithril's built-in router. Dead simple, yet expressive, and it supports dynamic imports as well as decoupling the path name from the routing method: https://github.com/soulofmischief/feathers-mithril-webpack-pwa-starter/blob/master/client/router/routes/index.js https://github.com/soulofmischief/feathers-mithril-webpack-p... https://github.com/soulofmischief/feathers-mithril-webpack-pwa-starter/blob/master/client/router/routes/Home.js https://github.com/soulofmischief/feathers-mithril-webpack-p... https://github.com/soulofmischief/feathers-mithril-webpack-pwa-starter/blob/master/client/lib/feathers/auth.js https://github.com/soulofmischief/feathers-mithril-webpack-p...