Comments on Accessibility: The Missing Ingredient

18 Reader Comments

Back to the Article
  1. You seem to be conflating the need for accessible websites with the use of ARIA roles.

    It’s important to make clear that you do not need to use ARIA roles in order for a site to be accessible.

    For HTML markup use a visually hidden “skip to content link” at the top of the page and then make sure, where possible, to use ordered headers (On some pages, like the homepage, it may not make sense to use ordered headers from h1 -> h6). There’s more, of course, but these two are a good starter.

    Having been a contractor in London for a number of years I used to ask a preliminary question, Do you aim to create accessible websites?

    This has been answered no so many times I don’t even bother asking it now. These are major multinational companies including one in the eduction sector.

    It’s just not on their radar. I suppose if there were was a well-publicised court case then this state of affairs may change.

    Copy & paste the code below to embed this comment.
  2. Agree with DivisiveCotton above. In general webdev workflow, ARIA should be the last task. Your article is not really about accessibility but screen reader accessibility/ARIA. Also, know that ChromeVox is the least used screen reader (and results between screen readers can vary a lot).

    Copy & paste the code below to embed this comment.
  3. Hi Andrew,

    Props to you for demonstrating hands-on effects of making a common use of the web more accessible. I enjoyed reading this. Given what you’ve learned, I’d like to see you write something similar on responsive web design specifically for people with low-vision. I’m working on a product called sitecues ( to make any website easier to read and use - so I’m particularly interested in font styles, what does/doesn’t work on mobile, etc.


    Copy & paste the code below to embed this comment.
  4. Couldn’t agree more that accessibility needs to be considered as just another part of any web design/development project. ARIA can be especially tricky, but it is very important, so it’s always great to see these types of articles on ALA.

    I do have some reservations about your particular ARIA example.

    First, I think there’s a problem with relying on Chromevox with this example because Chromevox has a unique relationship with Chrome and the way it makes the DOM, page content and functionality accessible, as compared with the two most popular screen readers in use, JAWS and NVDA. This is not always a problem with demos like these, but it becomes one when we look at the effect of role=“application”.

    In the first pass of the Robot Shopper demo, things actually work pretty well already with Chromevox and Chrome. Arrowing from product to product, Chromevox reads all the content in each product SECTION element, that is, the product’s name, price and details. With NVDA in Firefox, on the other hand, the use of role=“application” on the BODY element forces NVDA into application mode, and so the name, price and details text content associated with each product is not available unless the user manually changes to browse mode. With JAWS in IE, things are even weirder: everytime you arrow to another product, JAWS starts reading all the content from the beginning of the page. These are known pitfalls of role=“application”, but they get no real attention in the article.

    In the second pass of the demo, things are much improved for JAWS in IE, and especially for NVDA in Firefox: access to the product name, price, and details is much more straightforward. In fact, when arrowing from product to product, NVDA in Firefox announces all the content for each product. This doesn’t appear to be a result of any of the ARIA or other fixes discussed in the article. Instead, from what I can tell, it’s because role=“list” has been added to the DIV wrapping the four product SECTIONs, and role=“listitem” to each of the SECTIONs themselves. As such, Firefox identifies the DIV as a list in the accessibility API through which NVDA interprets the page. Similarly, each SECTION is considered a list item, and as such each SECTION’s entire contents comprise the accessible name for that SECTION as represented in the accessibility API. That is how Firefox and the accessibility API deal with list items. In turn, for each product SECTION cum list item, NVDA reads out all of its content to provide a really helpful user experience.

    Some discussion of why role=“list” and role=“listitem” are used and what effect they have in the context of role=“application”, or of other ways to make the non-interactive text content associated with each product easily accessible for a screen reader when it’s in application mode, would have been useful. As it is, I think there’s a danger that readers might walk away from this article thinking that all they need to do to make a widget accessible to screen readers is apply role=“application” and some custom keyboard actions.

    Copy & paste the code below to embed this comment.
  5. I agree with the sentiment from WebAXE, that ARIA is “last”, but only because the idea is you use the correct HTML element in the first place (which should then get you the needed roles without doing it by hand) and only *then* diving into ARIA.

    However, working in e-commerce, it’s simply a fact that any reactive e-commerce setup is going to have lots of thingies that DoStuff which have no associated HTML semantics, and lots and lots of Buttons that DoStuff depending on who they’re sitting next to or what section of the page their in, and lots of data-foo attributes. 

    So for what I do all day, and for examples like the above (a shopping cart), ARIA actually does need to be used pretty much right off the bat. Yes, with good HTML, but not first one and then the other, but both of them together as you build, just as you would have your alt text at the very moment you write your image code.

    And because e-commerce is an example where ARIA is necessary and shines, I like the idea of this article using e-commerce as an example. It would be very nice not to have the application role in the article, as I think back to my time looking at code examples on A List Apart years ago when learning things like writing bits of Javascript. Yeah, those pages got re-opened just to grab code. People will do that here too: code examples are what makes articles like the ones here nice. So for this reason I’d change stuff in the code above as edits.

    Chrome Vox is the One Very Strange Child Who Insists On Doing Things Completely Different From Everyone Else. Not that it’s got low usage, but that it doesn’t use the DOM the way every other screen reader does (uses Javascript to do everything in-browser, as opposed to other readers who interface with the computer’s applications also outside the browser).

    Copy & paste the code below to embed this comment.
  6. Hi Andrew,
    thanks for this article! I do applaud the level of detail you provide and the step by step guidance you provide to making this shopping cart more accessible.

    I do have some issues with some of the semantics, though. Jason and others have already pointed out a few questions/problems with this example. But I would like to draw attention to the start of the first example, the role “application” you are using. Two years ago, I wrote a lengthy article about role “application”, and that special care should be taken when using it, and when not. The most important point: The role “application” takes away all means of getting to document details. While you are right in stating that you are conscious about keyboard navigation, and your aria-labels and other techniques provide semantic info for most of the controls, I can show you an example where this falls on its head right in your example. :-) And that is in the shopping cart dialog. Role “dialog” is an implicit role “application”. And while you can nicely tab to the buttons, a screen reader user using JAWS or NVDA has no easy access to the items in the cart. The quantity, individual and total prices are not keyboard navigable, and neither is the total of the cart. One has to use cumbersome object navigation (NVDA) or touch cursor (JAWS 15 and above) navigation to actually get to this info, because it is not available otherwise. And that is because roles “application” and “dialog” take away all standard browsing functionality AKA the virtual cursor. The solution to this problem is to either do away with that “dialog” role, and allow standard navigation, and just set the focus when the cart becomes visible, which will redirect virtual cursors, too. Or make the table items tabable, too, so users can get to the relevant info more easily.

    Second issue: aria-hidden. Yes, this is a red cloth for me, and your example plainly shows that aria-hidden is absolutely not necessary here. Use display: none; and display: block; or whatever for your dialog, and that will hide and show the dialog for screen reader users without having to resort to the inconsistent and error-prone aria-hidden.

    Third issue: role “listitem” is the wrong role for a container with role “listbox”. “listitem” corresponds to a html:li element, which is not by definition an interactive control. The correct role to use is role “option”. With a parent with role “listbox”, this acts similar to a html:select with size > 1, and is exactly what you want here. With that, screen readers like JAWS and NVDA will automatically allow forms or focus mode on the listbox, which obsoletes your need for role “application”, and will make all the rest of the document available. And that, btw, includes the nice landmark roles you put there, which are also not used by screen readers that rely on a virtual cursor if you force them into application mode. :-)

    Sorry for being so blunt, but your article touches on two of my favorite “do not use” subjects within WAI-ARIA: role “application” & friends, and aria-hidden.

    Copy & paste the code below to embed this comment.
  7. Hey what a great article. I really liked how you broke things down so that even someone as new as myself could understand and learn something new. I will keep all of this in mind as I continue on my learning to code journey!

    Copy & paste the code below to embed this comment.
  8. Great article, but why start here? The accessibility of the interface with the keyboard is only a small part of WAI-ARIA. Why not begin with just making the information of a page more accessible by putting the content on top of the source document? Most big websites out there don’t even bother. Or upholding the pragma of only one <h1> per page. Or the order of headers (h1,h2,h3.. in that order). Or the tenacious use of “_blank” in an anchor for opening another tab. Or opening in another tab alltogether. Skiplinks? Scripted menus? I could go on and on.

    Blunt mode: As long as (the larger) corporations are not penalized by law because of a non-accessible website, this kite will never fly. Why?
    Making a website or an app accessible means it costs more money and companies will not pay more for something that is not directly related to profit. They just go to the cheapest developer.
    I don’t say I like it but it is the truth, corporations do not engage in ‘no profit yielding’ social commitment.

    By the way, I would advise anyone NOT to use new HTML5 tags. Until HTML5 is an official standard by terms of the W3C it is not good practice and unneccesary to implement it. Just wait to 2018 or so, when HTML5 (at the soonest) could be made a full-fledged W3C standard.

    Copy & paste the code below to embed this comment.
  9. By the way, I would advise anyone NOT to use new HTML5 tags. Until HTML5 is an official standard by terms of the W3C it is not good practice and unneccesary to implement it. Just wait to 2018 or so, when HTML5 (at the soonest) could be made a full-fledged W3C standard.

    This is not useful advice for a number of reasons.

    Developers can and do use features when they are implemented in browsers (i.e. supported). Interoperable implementation is a much better metric to base feature use on. It is factually incorrect. HTML5 is expected to become a W3C Recommendation in Q4 2014 (i.e in about 6 months) not 2018. The W3C itself uses HTML5 in its sites.
    Nowhere does the W3C state that HTML5 features should not be used until HTML5 becomes a Rec.

    Copy & paste the code below to embed this comment.
  10. Most important, this hard work will yield a more usable product for all customers and a more readable codebase for developers.
    Accessibility is not a extra work, she ask for quality and i think all we take advantage. Who would accept a rough job from a plumber? Why for web works have to be different?

    Copy & paste the code below to embed this comment.
  11. In addition to Steve Faulkner’s advice above it also bears mention that part of the W3C standards process (depending on the specific charter) is to have working implementations in the wild.  This means browsers must support it and developers must use it.

    Copy & paste the code below to embed this comment.
  12. Oy. I found this article very informative as a foundation for accessibility specifically geared toward web applications (rather than just web pages).

    What I found distressing is the comments and unwarranted criticism coming from clearly newly experienced accessibility people. With each new web technology that comes out (not that accessibility or ARIA is new) there are always arrogant people that seem to be bent on the notion of doing it the “right” way. In other words - their way.

    Like many things in web design and development… there is no “right” way to do accessibility. In fact, W3C is quite clear on this fact:

    “Techniques are informative—that means they are not required. The basis for determining conformance to WCAG 2.0 is the success criteria from the WCAG 2.0 standard—not the techniques.
    W3C cautions against requiring W3C’s sufficient techniques. The only thing that should be required is meeting the WCAG 2.0 success criteria.”

    In other words, it doesn’t matter HOW you get accessibility done… it’s just that it works and works well. Start with ARIA… end with ARIA… it doesn’t matter. Just make sure it works and meets the success criteria.

    The biggest lesson I’ve learned is that it doesn’t matter how good you think you are… if a visually impaired person can’t use your site it doesn’t matter what technique you use.

    In other words, USER TESTING. It’s more important than any technique your arrogant, non-visually impaired geek brain can come with. And user-centered user-testing is a key part of good UX.

    I know appeals to authority aren’t considered good arguments in a debate. But, I’m going to use one here: As a someone who’s been designing and developing web sites and web applications professionally for almost 20 years (and over 10 years as an online communications amateur before that) and who specializes in accessibility ... I’m going to tell you there is NO “right” way to do anything and it could always be done better. Bottom line: It just has to work well. Always user test. Even the biggest know-it-all will be brought down by someone who tries to use their software and fails.

    Copy & paste the code below to embed this comment.
  13. The point I tried to make (rather bluntly in retrospect) is that HTML5 is all good and well, learning the how and why to XHTML and basic XML is the foundation on which you build. XHTML5 is in this way an extension of my possibilities on the web. But the logic in it is the same: It’s better for data if you do it right.
    For example, take this website, the \<blockqoute\> tags in the code contain plain text, not \ blocks. It is not proper XHTML5 coding and I am rather positively convinced that there is a reason behind it to do so, be it for SEO or for speed (both confirmed by yours truly).

    Hey, I love HTML5 and it’s new features, I use it, everybody uses it. But I always (well, not always) remember that the internet is based on information in the first place, so that is where my attention goes out to. I can recommend a short XML Basic simple class to any starting webdeveloper.

    Copy & paste the code below to embed this comment.
  14. Excellent post!

    The missing ingredient could well be the image of the robotic cat, though… I would have to add that to my shopping cart together with the jet pack!!! ;)

    Torsten @ MightyTravels

    Copy & paste the code below to embed this comment.
  15. Good article and comments. To put things in perspective of why organisations need to support accessibility needs within their products and services offering are made in this business paper “The untapped Billion”.

    Copy & paste the code below to embed this comment.
  16. Sorry, commenting is closed on this article.