Increasing Accessibility

Published 12 hours, 9 minutes 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 “meyerweb.com” 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 "meyerweb.com" 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?