Posts in the Accessibility Category

Headings and Labels

Published 1 month, 3 days ago

Following on my last two posts about accessibility improvements to meyerweb, I’ve made two more adjustments: better heading levels and added ARIA labels.

For the heading levels, the problem I face is one familiar to many authors: what makes sense as an <h1> in some situations needs to be an <h2> in others.  The most common example is the titles of blog posts like this one.  On its permalink page, the title of the page is the title of the post.  There, it should be an <h1>.  On archive pages, including the home page of meyerweb, there are a number of posts shown one after the other.  In those situations, each post title should be an <h2>.

Part of the redesign’s changes were to write a single PHP routine that generated posts and their markup, which I could then simply call from wherever.  So I added an optional function parameter that allowed me to indicate the context in which a post was being placed.  It goes something like this:

<?php blogpostMarkup("archive"); ?>
function blogpostMarkup($type = "standalone") {
    if ($type == "archive") $titletag = "h2"; else $titletag = "h1";
    // …markup is all generated here…
    echo $output;
}

Or code to that effect.  (I did not go copy-paste from my actual code base.)

So now, heading levels are what they should be, at least on most pages (I may have missed updating some of my old static HTML pages; feel free to point them out in the comments if you find one).  As a part of that effort, I removed the <h1> from the masthead except on the home page, being the one place it makes sense to be an <h1>.

As for ARIA labels, that came about due to a comment from Phil Kragnes on my last post, where he observed that pages often have multiple elements with a role of navigation.  In order to make things more clear to ARIA users, I took Phil’s suggestion to add aria-label attributes with clarifying values.  So for the page-top skiplinks, I have:

<nav role="navigation" aria-label="page" id="skiplinks">

Similarly, for the site-navigation bar, I have:

<nav role="navigation" aria-label="site" id="navigate">

The idea is that screen readers will say “Page navigation region” and “Site navigation region” rather than just repeating “Navigation region” over and over.

Other than cleaning up individual pages’ heading levels and the occasional custom layout fix (e.g., the Color Equivalents Table needed a local widening of the content column’s maximum size), I think the redesign has settled into the “occasional tinkering” phase.  I may do something to spruce up my old Web Review articles (like the very first, written when HTML tags were still uppercase!) and I’m thinking about adding subnavigation in certain sections, but otherwise I think this is about it.  Unless I decide to go really over the top and model my Tools page after Simon St. Laurent’s lovely new Grid design, that is…

Of course, if you see something I overlooked, don’t hesitate to let me know!  I can’t guarantee fast response, but I can always guarantee careful consideration.


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 “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!


How Do I Increase Accessibility?

Published 1 month, 1 week ago

I have an accessibility question.  Okay, it’s a set of questions, but they’re really all facets of the same question:

How do I make my site’s structure the most accessible to the most people?

Which sounds a bit broad.  Let me narrow it down.  Here’s the basic layout order of most pages on meyerweb:

  1. Masthead
  2. Navigation (in a <nav> element)
  3. Main page content (in a <main> element), occasionally with a sidebar
  4. Footer (in a <footer> element)

But this is, at the moment, the source order of those pieces:

  1. Masthead
  2. Main page content (in a <main> element), occasionally with a sidebar
  3. Navigation (in a <nav> element)
  4. Footer (in a <footer> element)

The difference is the navigation.  I put it later in the source order because I want those using speaking browsers to be able to get the content quickly, without having to tab through the navigation on every page.

But is that actually a concern, given my use of a <main> element for the main content of the page?  And the <nav> and <footer> elements, do those also help with jumping around the page?  If not, what’s the best-practice structural order for those pieces?

If so, does that mean it’s okay to put the navigation back up there in the source order, and stop doing wacky things with the order element to place it visually where it isn’t, structurally?

I have the same questions for those who use keyboard tabbing of the visual layout, not speaking browsers.  What’s the best way to help them?  If it’s tabindex, how should I order the tabbing index?

And in either case, do I need skip links to get people around quickly?  Do I want skip links?  Do my assistive-technology users want skip links?

Maybe the real question is “Given this layout, and my desire to make getting to main content and other pieces of the page as easy as possible for those who rely on assistive technology, how should I structure and annotate the content to raise the fewest barriers for the fewest people?”

Unless, of course, the real question is one I don’t know enough to ask.

Can you help me out, accessibility hivemind?  I’d really appreciate some expert insight.  All my instincts are more than a decade out of date.