Screen Reader Support for new HTML5 Section Elements

Introduction

I will be giving a talk at John Slatin AccessU on May 9, 2016 on HTML5 Accessibility. I will be discussing the new elements in HTML5 that help to support better accessibility. I was doing some research on how well some of these elements are supported by the various screen readers and thought I would share it here.

Elements Tested

I have created a very simple page that formats a newsletter using these new elements. I used the following section elements:

  • header
  • section
  • nav
  • article
  • aside
  • footer

I have also included the ARIA role attribute to mark the banner, search, and main regions. You can see this simple page here: http://weba11y.com/Examples/SimpleNewsletterARIA.html.

Code Snippet

Here is a partial code listing to show the general usage of elements (the footer is not included). I have bolded the elements that were tested.

<header>
  <h1>My Newsletter</h1>
    <section role="search">
      <h2><label for="search">Search: </label></h2>
    <input type="text" id="search"><input type="submit" value="Go">
    </section>
</header>
  <nav>
    <ul>
      <li><a href="#top">Top Stories</a></li>
    ....
    </ul>
  </nav>
    <section>
      <header>
        <h2 id="top"> Top Stories</h2>
      </header>
      <article>
      <header>
        <h3> Story 1 </h3>
      </header>
        <p>Here is the first top story</p>
        <aside>
          <p><a href="moreStory1.html">More info about top story 1</a></p>
        </aside>
      </article>
.....

Some might argue that this is a bit of overkill but it shows the possible use of the elements for organizing a page and adding structure.

Testing Environment

I tested on Windows 10 with JAWS version 17.0.1806 and NVDA version 2016.1. I used Chrome 49.0.2623.112m and Firefox 45.0.2 and IE 11.0.10240.16724. The results were similar in all browsers. I was not going to test with IE 11 nor Edge because Steve Faulkner’s HTML5Accessibility.com page indicates that these elements are not supported by those browsers. That probably explains why the results were different between JAWS and NVDA in IE 11. *Updated: On repeated testing I can not get IE 11 to announce any of these elements. I’m not sure how I got these to work previously? Thus,the IE 11 results are probably not accurate. As expected, none of the semantic section elements were announced by Edge.

I also tested with VoiceOver using OS X 10.11.4 and Safari 9.1 (11601.5.17). VoiceOver supported most of these items once I interacted with the HTML content (via VO+shift+down arrow) and navigated through the page. As I interacted with the content the respective regions were announced and visibly outlined. The sections were not identified when reading the entire page via VO+a. I have not tested any mobile configurations, yet.

I tried to use the “default” and most verbose settings of the different screen readers. Obviously customization of the settings may change these results.

I tested two configurations for header, one with role=banner and one without the role. A header that is not embedded in a section should get the default role of banner. I wanted to test how the screen readers handled this additional role because in the past adding the role=banner caused some screen readers to speak it twice. Currently the W3C Nu HTML Checker will flag a top level header element with role=banner as a warning, “The banner role is unnecessary for element header.” I also tested sections with role=search and role=main and included them in the table. Note that a section element is not announced by itself, it needs a landmark role in order to be spoken.

Results

Okay, FINALLY after all that preamble here are the results! They are not terribly exciting since nearly all the elements are supported in the tested configurations.

Desktop Screen Reader Support for HTML5 Section Elements.
Windows 10 with Chrome 49, Firefox 45, and IE 11 OS X 10.11.4 with Safari 9.1
Element JAWS 17 NVDA 2016.1 VoiceOver
Header
no role
Yes, announces beginning and end as "Banner". IE 11- also (incorrectly) announces headers within a section as "Banner". Yes, announces beginning, "Banner Landmark". Yes, announces beginning and end as "banner".
Header
role=banner
Yes, announces beginning and end as "Banner", spoken only once. Yes, announces beginning, "Banner Landmark", spoken only once. Yes, announces beginning and end as as "banner", spoken only once.
Section
role=search
Yes, announces beginning and end as "Search region". Yes, announces beginning, "Search Landmark". Yes, announces beginning and end, as "search".
Nav Yes, announces beginning and end as "Navigation region". Yes, announces beginning, "Navigation Landmark". Yes, announces beginning and end as "navigation".
Section role=main Yes, announces beginning and end as "Main region". Yes, announces beginning, "Main Landmark". Not announced in IE 11. Yes, announces beginning and end as "main".
Article Yes, announces beginning and end as "Article". No No
Aside Yes, announces beginning and end as as "Complementary". Yes, announces beginning, "Complementary Landmark". Not announced in IE 11. Yes, announces beginning and end as as "complementary".
Footer Yes, announces beginning and end as "Content Information". Yes, announces beginning as "Content Info Landmark". Not announced in IE 11. No, as tested with a <p> inside of the footer. Yes, announced beginning and end, as "footer" if no other element inside of the footer. This could use more testing since a footer can also be inside other section content.

Conclusion

The new HTML5 section elements are well supported on Windows 10 in Chrome and Firefox and fairly well supported in IE 11 with the JAWS and NVDA screen readers. VoiceOver and Safari also support these elements. Let’s hope that Edge will provide the necessary underlying support soon.


About Becka11y

Web Accessibility Consultant with 30+ years in the software industry and 12+ years of direct accessibility innovation.

5 comments:

  1. Hi, Scott,
    I had to do a view source to see that you are asking about the code element. I guess you have to escape the angle brackets surrounding the <code> element for it to display properly in the comments section.
    I’m not exactly sure of the problem you are describing. If I use NVDA with the default settings it will speak all of the angle brackets associated with HTML code. Are you trying to avoid this and have the screen reader say, “label element,” instead of, “less than label greater than?” While it may be tedious, I think that screen reader uses are expecting that and can tweak the punctuation settings if necessary.

    I initially thought that your question referred to identifying a section as code. For that you could use a figure element and fig caption to include a caption that identifies the section. Or, just explain in the text that the following section is programming code and identify the language. This will help all users, not just those using the screen readers. Some people may not immediately make the connection to differently styled text as a representation of programming code.

  2. I recently found your blog and as a web accessibility professional, find it useful and informative. I’m looking for a solution to make the element accessible to screen readers. Obviously, screen readers don't read most punctuation or speak the code as you might say it verbally. So is the only way to make this accessible to developers or students who are blind through an alternate text description?

  3. I recently found your blog and as a web accessibility professional, find it useful and informative. I’m looking for a solution to make the element accessible to screen readers. Obviously, screen readers don't read most punctuation or speak the code as you might say it verbally. So is the only way to make this accessible to developers or students who are blind through an alternate text description?

Leave a Reply

Your email address will not be published. Required fields are marked *