Hacker News Reader

Comment by gampleman | Hacker News Reader

Is this really true? Messaging like this will cause a lot of developers to just give up. Most places I've worked at did accessibility at best as a best effort sort of thing. After reading this, there will be no attempts made to improve the state of affairs.

Perhaps that will be an improvement? I don't know.

View on HN

Let’s give a concrete and catastrophic example of something I’ve seen in the wild in a professional product. A developer there had obviously seen the application role[1] in the ARIA specs, thought “I’m building a web app”, and added it to their html element.

What role="application" means to assistive tech is: “I’m building a really complex application, so I’m going to handle absolutely everything for you, I don’t want you to have any default behaviour.” This meant that the web app in question was 100% unusable for any people using assistive technology, as that was broadly as far as they’d got with accessibility support.

[1] https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...

Stories like this make me wonder if we could build a Chrome extension with a collection of crowd-sourced site-specific accessibility tweaks. Things like removing that bad ARIA tag or bodging in proper labels or tabindexes. It wouldn't be perfect, but neither is AdBlock and it offers a lot of benefit.

That does seem catastrophically misguided. I’m more curious about the more common case where tags are used as documented (and I really wish the documentation was better), but perhaps not completely. For instance we have a Finder like UI in our web app that conceptually is a treegrid, but we don’t support all of the keyboard interactions advised at the above website.

Should we remove the role attributes?

What would be better for your users? What have you discovered in research?

If you don’t know, and you’re not doing research, your best bet is to match the standardised semantics and interactions as best as possible, or at least have backlogged items to do so.

ARIA is often a compensating technology more than a primary solution. I try to not use ARIA in my own code aside from the role attribute. I instead rely on the clear navigation and order HTML content and events as my primary solutions.

Using the right elements (like button instead of a div) will take you very, very, very fair with little to no additional work.

+1 here... <button> vs <a> in particular... if it's programmatic behavior, use a styled button if you want it to look like a link, and vice-versa for navigation behaviors.

I will add that a good component library should also handle some of this for you... in particular menu navigation, popouts/drawers etc. That said, can't say how many sites/apps have really broken behavior with this.

The statement is about encouraging folks to use the platform: `<button>Hello!</button>` over `<div role=button tabindex=0>Hello</div>`

It is true. This is not messaging. They are not selling you ARIA.

If you are developer, just write semantically clear HTML instead. Just doing something is worse than doing nothing in accessibility.

This adage has been "the first rule of ARIA" since the beginning.

There are a few ARIA "widgets" that have no HTML equivalent, such as Tabs or a spreadsheet-like Grid. Those are heavily documented so you can basically copy and paste whenever you need them.

Avoiding sprinkling ARIA on already-semantic HTML, because this can lead to confusing or inconsistent behaviors for the end user.

Reply on news.ycombinator.com