3 ms·

From the part on accessibility: > But we also need to make it easy for product developers to do the right thing. What can we do to make accessibility a defaul

From the part on accessibility: > But we also need to make it easy for product developers to do the right thing. What can we do to make accessibility a default rather than an afterthought? Yes! We accessibility advocates have been wishing for this for decades. In the context of web development, application developers should rarely, if ever, have to reach for the ARIA role attribute, because they should be able to re-use existing rich widgets rather than implementing custom ones. I'm hoping that Web Components-based toolkits like the new Ionic 4 will help here. Then project boilerplates should include some kind of accessibility testing by default, so developers will have to go out of their way to ignore it.

ehnto 8y ago
I have had this in mind for years but never followed through with it. Do you know of any groups currently working on the problem? The dream is framework agnostic Web Components that "just work" in a modern browser. You can make it happen with a bit of polyfill javascript. My worry has been spending a bunch of effort making them and then having to maintain separate sets for all the different frontend "web component-ish" frameworks so that people would actually use them.
- nojvek 8y ago
  Framework agnostic is hard because building a complex UI toolkit always needs some underlying way of binding model control logic and rendering together. So if you don’t end up using a modern popular framework, you have already invented one that is undocumented.
danabramov 8y ago
For React, https://ui.reach.tech/ https://ui.reach.tech/ is a project that attempts to help that.
- ggurgone 8y ago
  React Native for Web also aims to raise the bar.
austincheney 8y ago
The way I have seen accessibility introduced successfully is to make the QA the accessibility advocates. Train them up on the WCAG 2.0 guidelines and build their confidence up. Its ok when they open an accessibility defect that ends up being a false positive. Ensure the QA has the tools in place to get into the browser's developer tools and look at the structure of things and how various UI controls are accessed. As the QA gain mastery over accessibility the developers are on the hook to implement the proper controls. It is easy to get upset when developers look like a bottleneck and hold up releases, but nobody gets upset when QA identifies potential liability and a shitty product.
darekkay 8y ago
The "make accessibility a default rather than an afterthought" phrase was exactly what I've been looking for. I'm currently summarizing my evaluation of over 20 UI frameworks for an upcoming blog post. It's a pity to have even accessibility-aware frameworks like Bootstrap going with inaccessible colors by default - on purpose [0]. Yes, it is not hard to customize those colors, but many people simply go with the defaults, leading to an inaccessible site. [0] https://getbootstrap.com/docs/4.1/getting-started/accessibility/ https://getbootstrap.com/docs/4.1/getting-started/accessibil...

ehnto 8y ago

I have had this in mind for years but never followed through with it. Do you know of any groups currently working on the problem? The dream is framework agnostic Web Components that "just work" in a modern browser. You can make it happen with a bit of polyfill javascript. My worry has been spending a bunch of effort making them and then having to maintain separate sets for all the different frontend "web component-ish" frameworks so that people would actually use them.

nojvek 8y ago
Framework agnostic is hard because building a complex UI toolkit always needs some underlying way of binding model control logic and rendering together. So if you don’t end up using a modern popular framework, you have already invented one that is undocumented.

danabramov 8y ago

For React, https://ui.reach.tech/ https://ui.reach.tech/ is a project that attempts to help that.

ggurgone 8y ago
React Native for Web also aims to raise the bar.

austincheney 8y ago

The way I have seen accessibility introduced successfully is to make the QA the accessibility advocates. Train them up on the WCAG 2.0 guidelines and build their confidence up. Its ok when they open an accessibility defect that ends up being a false positive. Ensure the QA has the tools in place to get into the browser's developer tools and look at the structure of things and how various UI controls are accessed. As the QA gain mastery over accessibility the developers are on the hook to implement the proper controls. It is easy to get upset when developers look like a bottleneck and hold up releases, but nobody gets upset when QA identifies potential liability and a shitty product.

darekkay 8y ago

The "make accessibility a default rather than an afterthought" phrase was exactly what I've been looking for. I'm currently summarizing my evaluation of over 20 UI frameworks for an upcoming blog post. It's a pity to have even accessibility-aware frameworks like Bootstrap going with inaccessible colors by default - on purpose [0]. Yes, it is not hard to customize those colors, but many people simply go with the defaults, leading to an inaccessible site. [0] https://getbootstrap.com/docs/4.1/getting-started/accessibility/ https://getbootstrap.com/docs/4.1/getting-started/accessibil...