←back to thread

125 points robin_reala | 9 comments | | HN request time: 0.198s | source | bottom
1. gampleman ◴[] No.46203385[source]
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.

replies(5): >>46203428 #>>46203474 #>>46203552 #>>46203918 #>>46204092 #
2. askew ◴[] No.46203428[source]
The statement is about encouraging folks to use the platform: `<button>Hello!</button>` over `<div role=button tabindex=0>Hello</div>`
3. austin-cheney ◴[] No.46203474[source]
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.
replies(1): >>46206230 #
4. nabla9 ◴[] No.46203552[source]
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.

5. pickpuck ◴[] No.46203918[source]
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.

6. robin_reala ◴[] No.46204092[source]
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...

replies(1): >>46205008 #
7. tdeck ◴[] No.46205008[source]
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.
8. no_wizard ◴[] No.46206230[source]
Using the right elements (like button instead of a div) will take you very, very, very fair with little to no additional work.
replies(1): >>46207567 #
9. tracker1 ◴[] No.46207567{3}[source]
+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.