Screen readers, ARIA & HTML5 (too much information)

Most current screen readers support ARIA to one extent or another, and many now support some features of HTML5 as well. With ARIA and HTML5 making increasing amounts of semantic data available to screen reader users, it’s really easy to inadvertently overload people with too much information.

Let’s take an example that crops up from time to time:

<ul role=”navigation”>
<li><a href=”home.html”>Home</a></li>
<li><a href=”about.html”>About us</a></li>
<li><a href=”contact.html”>Contact us</a></li>


This approach is problematic for two reasons: It breaks the intended relationship between ARIA and HTML, and it offers a poor experience for screen reader users.

ARIA HTML5 relationship

Here’s how the ARIA specification defines the navigation landmark role:

A collection of navigational elements (usually links) for navigating the document or related documents.

At first glance this seems to suggest that the navigation role can be applied to the <ul>, because it’s a collection of navigational links. It actually causes a conflict though. The <ul> element already has an ARIA role of “list”, and it’s treated as a list by other accessibility APIs.

Here’s how the HTML5 specification defines the <nav> element:

The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links.

The <nav> element was purpose built to contain a number of navigational elements. This makes it a much closer fit for the ARIA navigation role than the <ul> element. In fact the ARIA navigation role maps directly to the HTML5 <nav> element.

Screen reader experience

When the navigation role is applied to the <ul> element it creates extra verbosity for screen readers that support both ARIA and HTML. For example NVDA announces “Navigation landmark” when it encounters the start of the <nav>, then again when it encounters the navigation role. Jaws does the same thing with a slightly different announcement (“Navigation region”), and it also announces the end of each region. It announces “Navigation region end” when it encounters the </ul>, then again when it encounters the </nav>.

Things are further complicated by the conflicting roles: The native list role and the applied navigation role of the <ul>. NVDA announces “Navigation landmark, List of 3 items”. It does this in Firefox because the accessibility API concatonates the two roles, but in Internet Explorer it has to go into the DOM to create the same effect. Jaws appears to ignore the accessibility APIs entirely. In Firefox it fails to announce the list, although it does preface each list item with “Bullet”. In Internet Explorer it does neither, effectively ignoring the list semantics altogether.

The upshot is that the navigation role should be applied to the <nav> element. This represents the relationship between ARIA and HTML5 correctly, prevents the loss of the list semantics, and reduces screen reader verbosity to a manageable level.

<nav role=”navigation”>
<li><a href=”home.html”>Home</a></li>
<li><a href=”about.html”>About us</a></li>
<li><a href=”contact.html”>Contact us</a></li>


8 comments on “Screen readers, ARIA & HTML5 (too much information)”

Skip to Post a comment
  1. Comment by Birkir Gunnarsson

    Yes, this is becoming very noticeable. With Jaws 14, for instance, it now announces “region” wherever it sees the section element. Some people have started adding an article element to every single headline on a news site. I recently saw a site with both the article and section elements for every single news section, creating two landmark type announcements by Jaws for every one of the 20 or so news headlines with snipets, making aria landmarks totally useless. I asked the site owners if they could take out the article tag and replace the section with a div for now, fortunately I was doing an accessibility review and the site owners obliged.

  2. Comment by Stomme poes

    My rule of thumb so far is, main landmark roles for chunks of page, and aria roles/states/etc for when I can’t rely on basic HTML semantics or code source order to make things make sense. So in that sense, ARIA is a bit of an afterthought: except the landmarks, most of my ARIA is added to markup I’ve already written after I’ve taken a look at the existing markup. What doesn’t work? Patch with ARIA *if* markup can’t be re-arranged. This is partially due to those AT and older browsers who don’t know ARIA.

  3. Comment by Monica

    Birkir, please do not ask web authors to change article and section tags to div tags or remove them for accessibility. I know you want websites to read well, and I don’t think you’ve thought through the negative effects of what you’ve suggested here.
    Removing the section tags in the instance you’ve described would make sense since you don’t need those for every post in conjunction with the article tag. Removing the article tag for each headline is going to hurt the site in several ways down the line, and I don’t think you intended that. When you remove article tags, you are undoing the symantic meaning of a website’s elements. This isn’t just a tag substitution. It has real world consequences. This can have a negative impact on the ability of machines to index sites effectively and target web services to end users. It also limits the ability of screenreaders to navigate by article, something I would think you would appreciate having the ability to do, especially on sites where they don’t use a heading tag for each new article or post. In this case, you’ve asked the site owner to reduce functionality because of verbosity introduced by a screenreader. That is the fault of the screenreader manufacturer, not the website author or the article tag in HTML.
    Rather than reducing symantic meaning of sites, please advocate for better default verbosity settings in your screenreader of choice. Advocate for better support of HTML 5 elements. That strategy would let everyone win by taking the big picture of web access into account.
    In the future, the symantic meaning of web elements is going to increase in importance, and your suggestion of using a div tag forces that website to lose out on the benefits conferred by the article tag. It’s a band-aid solution that helps blind people in the short term but hurts the site in the long term, including blind users. This can have serious implications when it comes to the search engine optimization of a site and its ability to get specific posts found in web searches. I’d explain more here but think my comment would be too long.
    I believe solutions to bring accessibility to a site should allow us to coexist with sighted users while not hobbling the site’s performance and search engine optimization efforts. This means we’re responsible for changing things like verbosity on our screenreaders when needed, asking for changes that do not impact a site’s ability to function correctly, and making our needs known to our screenreader vendors.
    I am blind, and I teach web design to blind and visually impaired people. I teach them to use the article tag where there is a topic change on a web page and to politely decline requests to revert to the div tag unless there is no real meaning to their use of an article tag. I teach them to suggest turning off landmark verbosity for their site in the person’s screenreader if that bothers the user.
    Yes, accessibility matters, but it should not come at the cost of diluting the symantic meaning of website elements. That strategy hurts everyone, blind and sighted alike.

  4. Comment by ryanve

    Do you think it is good practice to include a skip-to-main link early in the markup, or does role=main make that redundant?

  5. Comment by Stomme poes

    ryanve, here’s my take on that:

    If we can’t assume all our visitors have a new browser or uptodate AT, and if we want to keep sighted keyboarders in mind (of course we do), skip links are then still a good idea. They are slightly redundant for a screen reader user using a newish screen reader on a newish browser; for everyone else they are still nice. Especially if you have a large menu between top of page and main content. 😛

  6. Comment by buckthorn

    With all due respect, I find the claims regarding the supposed “semantic benefits” of html5 tags to be highly overstated, if not unfounded, and certainly unproven. The semantic meaning of these tags is not always well-defined and can be in flux. The spec is still so incomplete and unfinished that some of these tags are still being removed (e.g., see hgroup). I agree that using both html5 tags and the corresponding aria roles can be redundant. One of the reasons why the aria roles have been recommended by some is because of insufficient browser support. Given all of the above, I favor staying away from the new html5 tags and sticking with divs plus the aria landmark roles. To say that this is “less semantic” and will somehow degrade the user experience or have some other damaging effect is nothing more than an assertion. My .02.

  7. Comment by Kevin

    Monica, could you clarify, it’s early here 🙂 Are you suggesting that the logical heading, and probably visually distinct, heading of each article shouldn’t be marked as a heading element in HTML 5.

    That is surely wrong and the mere tagging as a heading both conveys the same info as visual users get and provides the navigation that screen readers require.

    As ai said, it’s early here so I may have missed the point.

  8. Comment by Stomme poes

    I read Monica’s response as meaning, if you use article/section tags instead of divs, then some screen reader users have an easier time navigating in the cases where, for whatever weird reason, there is no heading tag present. And I think by heading she meant hx tags, not necessarily the header tag. She’s saying *if* there is no heading tag, you could at least navigate by article as a sort of backup.

    She’s a proponent of using diverse tags rather than divs, though I tend to agree more with buckthorn and have many doubts on the real, current semantics of these tags (the ideal semantics sure sound nice, it’s just that that’s not what we have today).

Comment on this post

Will not be published

This site uses Akismet to reduce spam. Learn how your comment data is processed.