Our post last week about the pitfalls of ARIA tabs pushed some buttons in the accessibility community. This week, Derek responds to the reactions and shares why we felt it was important to publish something that made our readers uncomfortable.

We suspected when we wrote the article we wrote last week that it might not be too popular. That it might be surprising. That some people might have very mixed reactions to it. The reactions we got on Twitter certainly seem to confirm our suspicions.

Some people were frustrated:

Some people were confused:

Some people came out in full support of the viewpoint that we believe in and published:

We kinda knew debate would happen, and we were okay with it. Why?

Because we have to question current practice. We have to question the guidance that we’re given. We have to question the direction in which we’re going—and whether it’s leading us to the right place.

Most of us in the accessibility field base our solutions on experience with assistive technologies (usually screen readers, if we’re all being honest), or we base them on working directly with people with disabilities. But how often are new solutions really and truly tested with people with disabilities? Not nearly as often as they should be.

I get why the article hit a sore spot with a LOT of people. It calls into question years of work on ARIA. It calls into question the trust that web pros place in accessibility people to get it right and provide the guidance that non-accessibility specialists need. It calls into question the things that you thought you knew. And all of that can be quite painful.

Best practice evolves. What is best practice today may be completely shunned in six month’s time. (Look at icon fonts.)

Accessibility is no different.

We shouldn’t be surprised when the accessible implementation we find today isn’t the pinnacle of accessibility tomorrow. We should find out whether or not a solution actually works well for people with disabilities in usability testing. We should question whether that complex structure is really the best solution—and whether ARIA is the best tool for the problem we’re trying to solve.

Because accessibility is often ignored, we sometimes think “anything is better than nothing” and that technically accessible solutions are “good enough.” But good enough often isn’t.

Simply Accessible doesn’t take on projects where usability testing is excluded from the work that needs to be done. We want to go beyond just meeting technical requirements. From where we sit, if it’s technically perfect but unusable by people with disabilities, it doesn’t matter that we followed all the rules.

Accessibility isn’t about specs. It’s about people. Our job is about making sure people can use things we make.

And so, we presented scenarios from the usability testing that we’ve done—because it’s a treasure trove of insight and goodness. I know that not everyone can do user testing. So that’s part of why we do it. And why we feel compelled to share our findings with you, our community.

5 thoughts on “ARIA thunder: why we published a controversial post (and why we’ll probably do it again)”

Read comments

  1. Birkir says:

    The problem with the article was that the poster did not fully use the semantically correct ARIA markup. No matter how valid your argument, if you do not fully use the correct markup, you cannot claim the result of confusion rising from that mark up is the fault of the spec. If you use an I instead of an h, and define and h2 heading as an , you can’t complain about the fact that is not supported by assistive technologies. This wasn’t as bad as that, but role=”tab” and role=”presentation” where both used on a a div element, which is wrong. Also the proposed solution included things like using aria-selected=”true” on a link, which is not permitted by the spec. You have to understand and use the spec correctly before you claim the spec is rubbish.

    1. Hi Birkir — I’m not quite sure I understand some of your comments that “This wasn’t as bad as that, but role=tab and role=presentation where both used on a a div element, which is wrong.” I cannot find role=tab or presentation used on div elements in the code sample. They’re used in links and list items, not divs.

      Also, you mention “the proposed solution included things like using aria-selected=true on a link, which is not permitted by the spec”– good catch… that was left over from when the role=”tab” was on the links.

      One final quick thing — we didn’t ever make the claim that the spec was rubbish. The spec is a thorough and detailed piece of work. What we did question (and will continue to question) is the usability of solutions that are created using that spec. It’s no different than questioning the ease of use of solutions that are created using HTML, CSS, or any other web technology.

  2. Birkir says:

    Again, I agree with the sentiment of the article. We often get lost in our ivory towers of specs and user agent accessibility interface mappings, and forget about the 60-year-old lady who is learning to use a screen reader for the first time. This is why I often volunteer to help end users in my native country of Iceland with difficult websites. But we can’t just ignore the fact the web is changing. We have to try and evolve along with the web when we can, ,and put our efforts into help our end users understand and take advantage of our ideas and our standards. But the solution is tnot to replace these standards with plain html and ARIA properties that are not valid with the elements we use. It is to participate in the making of the standards and to file bug with the assistive technologies that fail to communicate the markup in a useful and intuitive way to the end user.

  3. Stomme poes says:

    I remember the first time I ran into tab-panels. Extra unfortunate was that they were styled as a collection of links.

    I wasted too many precious minutes of my life tabbing and shift-tabbing over those things. Why can I only focus on the first item??? Had I not been a web developer who knew how to F12 and see why these links were broken, I would have done what all normal people do– assume the website is broken and leave. Even so, I was pissed and frustrated as a user.

    I still today have trouble with tab panels where the panels are taller than my screen. Because the panels hijack my up and down keys, I can’t scroll the page down to read the rest of the panel. Every example on an accessibility-related page has these cute, tiny, page-fitting panels, and they usually have something focusable inside. A lot of the ones I run into in the wild do not.

    The assumption that everyone with a screen reader automatically knows how to use these things is one problem,
    but the assumption that everyone who uses the keyboard is a screen reader user is almost worse. Without dev tools, you can’t see how something is supposed to work.

    If we’re going to just change how stuff has traditionally worked, then maybe we need a requirement that all places implementing this new, different-from-web way of doing things (and all new things too) should just have some instructions on the page. And not invisible ones for screen reader users, either.

    Just telling people how to use something can really help things a lot.

Hi there! We've closed the comments after a week of spirited discussion on this post. If there's something we've missed, please reach out and let us know.