Increasing Accessibility

Published 1 month, 1 week ago

Thanks to the fantastic comments on my previous post, I’ve made some accessibility improvements.  Chief among them: adding WAI-ARIA role values to various parts of the structure.  These include:

  • role="banner" for the site’s masthead
  • role="navigation" added to the navigation links, including subnavigation links like previous/next posts
  • role="main" for the main portion of a page
  • role="complementary" for sidebars in the blog archives
  • role="article" for any blog post, whether there are several on a page or just one

In addition, I restored skip links to the masthead of most pages (the rest will get them soon).  The links are revealed on keyboard focus, which I’m not sure I like.  I feel like these aren’t quite where they need to be.  A big limitation is the lack of :matches() (or similar) support in browsers, since I’d love to have any keyboard focus in the masthead or navigation links bring up the skip links, which requires some sort of parent selection.  I may end up using a tiny bit of enhancing Javascript to make the links’ UX more robust in JS situations, but still obviously available if JS fails.  And I may replicate them in the footer, as a way to quickly jump back up the page, especially to the navigation.

Speaking of the navigation links, they’ve been moved in the source order to match their place in the visual layout.  My instincts with regard to source order and layout placement were confirmed to be woefully out of date: the best advice now is to put the markup where the layout calls for the content to be.  If you’re putting navigation links just under the masthead, then put their markup right after the masthead’s markup.  So I did that.

The one thing I didn’t change is heading levels, which suffer all the usual problems.  Right now, the masthead’s “” is always an <h1> and the page title (or blog post titles) are all <h2>.  If I demoted the masthead content to, say, a plain old <div>, and promoted the post headings, then on pages like the home page, there’d be a whole bunch of <h1>s.  I’ve been told that’s a no-no.  If I’m wrong about that, let me know!

There’s still more to do, but I was able to put these into place with no more than a few minutes’ work, and going by what commenters told me, these will help quite a bit.  My thanks to everyone who contributed their insights and expertise!

  1. Nice work, and so fast, too!
    Getting headings right confounds many people, and it can be complicated for folks using CMS. The rule of thumb I use is that the heading that introduces the content unique to the page should be H1. It should also be the first heading inside the MAIN area. For this page, that would be "Increasing Accessibility" and on your home page, I would make "" the H1. If the CMS reuses the markup from a single post to populate the entries on the home page, then you will end up with more H1s than is desirable or useful.

  2. You really didn’t need to add (most of) those WAI-ARIA role values as they are the default values for most elements to which you applied them (and thus redundant). The only place where it is (eventually) justified is for a ul role=navigation and a div role=complementary I see in your source code. Spec and HTML validator advise against doing that.

    Another thing, your main navigation (nav) contains an h4 heading, but it is hidden even to screen readers – they won’t benefit from it. Perhaps add a aria-label?

  3. Thanks, Sarah! That’s the approach I want to take as well, but the problem of home pages is exactly as you describe: it means either decentralizing my post markup routines, or building in some sort of logic to vary the generated headings levels and editing their associated styles. Which is probably what I’ll do, in the end.

    Philippe, the recommendations I got (see, for example, this comment from Marco Hengstenberg) indicated that for older-browser support, explicit roles were needed even for elements that should have them implicitly. I also found them in the markup of the sites of people who do a lot of accessibility work, like Adrian Roselli. Given their intent, I feel like they are at least somewhat necessary.

    The <h4> is definitely an error on my part; I let it hang over from the previous design by mistake. Out it goes! Thanks for catching that.

  4. Did you pull back the skip links? I’m not seeing it appear.

    Regarding the roles, I would agree with others that you really don’t need them. Unless you expect people to be on older assistive tech. I feel that this has been supported by all major AT for at least 3 years, though others may know more. I would only apply roles manually if the only thing you’re allowed to touch a design with is to add some JS so that you’re adding the roles onto divs/spans via JavaScript, or if you know a major browser doesn’t natively support an element (e.g. Firefox has lacked support for dialog for a bit so manually adding role=”dialog” does help them out some). If you can use native HTML5 elements then do so.

    I would advise against adding roles on elements like an unordered list. That can confuse some semantices. It should stick to a nav element.

    Of course, adding the roles doesn’t hurt, it’s just something I wouldn’t be adding myself on a new site unless I had a specific reason for it.

  5. Really nice job on the redesign! I wasn’t able to watch any of your live streams, but I’ve bookmarked them and plan to watch from the treadmill soon.

    As far as the appropriate markup for the headings, if I understand it correctly (from reading Jeremy Keith’s HTML5 for Web Designers, Chapter 5, on semantics) it’s fine to have multiple <h1>s on the page as long as they are “scoped” by a sectioning element (like a <section> or an <article>).

    Thanks for sharing the responses you’ve received on accessibility. It’s good to hear that there’s value in having the markup in the same general order as the presentation.

  6. Thanks, Trace! My understanding is that was intended to be the case with the document outline algorithm, which browsers ended up not supporting. See Adrian Roselli’s 2016 article (with 2017 updates) “There Is No Document Outline Algorithm” and Steve Faulkner’s 2016 article “Computer says NO to HTML5 document outline”. I’m sad about this, as I completely want there to be scoped headings and a document outline and all that, but we have to work with what we have.

  7. Hey Brian, the skip links appear when they receive focus via tabbing. They’re not first in the document, but second (after the <h1>), something I should fix. As for the roles, I try not to assume too much about the tech that will be used to access the site, especially given the wide range of technology available around the world. So for me, explicit roles are worth including. Maybe by the time I redesign again, somewhere around 2031, I’ll be able to drop them…

  8. […] Increasing Accessibility: Earlier this week, Eric Meyer asked his blog readers how he could improve accessibility on his site. Two days later, he acted on those suggestions and explained his first steps for creating a more accessible site. […]

  9. Thanks, Eric, for that update on the document outline algorithm. I have a lot of unlearning to do!

  10. Regarding the inclusion of role=”navigation” on the unordered list in the banner, I have the following thoughts… Although this is not a common practice, I think there may be some merit if another ARIA attribute is included. The general rule is to provide labels for regions when more than one of the same type is included on a page. So, adding aria-label=”page” to the <ul> element would cause screen readers to speak “Page Navigation Region.” The navigation region following the banner could be labeled aria-label=”site”, causing screen reders to speak “Site Navigation Region.” Imagine a list of regions on a page; Page Navigation Region, Site Navigation Region makes much more sense and is more user friendly (accessible) than Navigation Region, Navigation Region…

  11. That’s a great idea, Phil! I’ve done exactly that, and will add distinctive labels to other navigation regions as well. Thank you for the suggestion.

  12. Have you tried using the :focus-within pseudo class?

    Wrap can wrap your header and nav elements within a div.focuser and the following CSS will reveal the #skiplinks whenever any element is focused within the div.focuser:

    .focuser:focus-within #skiplinks a {
    transform: translate(52em) !important;

    I plan on writing more about this technique, as well as some more advanced use cases on my blog “soon”.

  13. I have not, but I dig it, David! I suspect that will appear in my style sheet pretty darned soon. Thank you!

  14. From my testing, :focus-within in a selector kills the entire selector in IE11. So, yeah. Fun.

  15. Adrian, does this work for IE11 in your testing?

    #sitemast #skiplinks a:focus,
    #sitemast #skiplinks a:focus ~ a {transform: translate(52em);}
    #sitemast #skiplinks:focus-within a {transform: translate(52em);}

    That’s what I’m now using, with fingers crossed.

Leave a Comment

Management reserves the right to edit or remove any comment, especially when abusive or irrelevant to the topic at hand. HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <em> <i> <q cite=""> <s> <strong> <pre class=""> <kbd>

Comment Preview

If you're satisfied with what you've written, then go ahead...