How Do I Increase Accessibility?

Comments (12)

1. I’m definitely not part of the accessibility hive mind, but! I feel compelled to note I have Paul Robert Lloyd’s article on “Improving the Accessibility of 24 ways” open in another tab. If it’s not known to you, I think it’s great; and if you’ve already read it, apologies!

2. Quick response:

   • The keyboard tab order should match the visual layout of the page. Sighted keyboard users in particular can be thrown off if not.

   • The order attribute can be problematic, just like floats, absolute positioning, and grid regions. Ref: http://adrianroselli.com/2015/10/html-source-order-vs-css-display-order.html

   • Do not use tabindex unless necessary, and certainly never with a positive value. http://adrianroselli.com/2014/11/dont-use-tabindex-greater-than-0.html

   • Screen readers are the only tools right now that can navigate by region, so skip links have value for keyboard users who do not use screen readers.

   I am not quoting WCAG failures, but I am happy to have a longer conversation if you like.

   In short, structure the page as you want, without stressing too much about making special considerations for screen readers or other assistive tech. Make sure the flow is visually and keyboardly (?) consistent. Try to avoid special tricks if you don’t have solid guidance or experience.

   Also, I put my <nav> in the <header> and that appears before the (single) <main>.

3. Adrian already said most everything I was going to. It’s best to have the layout order be the same as the source order whenever possible. If you do that, you rarely have to fuss with tabindex.

   Depending on what’s in your sidebar, you might want to put it in an aside element.

   While it would be awesome if browsers supported keyboard navigation by landmarks, at least we still have scrolling.

4. Some thoughts—

   • <main> and <nav> and <footer> are helpful to screen-reader users, but their magic is unavailable to sighted keyboard users. (Screen readers add shortcut keys for landmarks, but people who don’t use screen readers don’t have that advantage.)

   • I’d put move up the navigation in the source order. As it is now, if a keyboard user wants to get to the navigation, they have to tab through the whole page.

   • If you move the navigation up in the source order, I’d add a skip link. They’re especially helpful to sighted keyboard users who don’t have access to landmarks.

   • And tabindex is a bit like using a weed-wacker in sandals: It can theoretically be okay if you’re very careful but it’s usually best avoided.

5. I’ve been on a11yslacker on gitter for a while and have listened to the fine folks at the Paciello Group for a while (though anything I say is of my own voice, I do not speak for them). I must say that Adrian is right on the money. Make your structure match your visual layout, avoid tabindex at all cost (though some browsers will do better if you give tabindex=”0″ on regions like your main that should be the recipient of focus — though be warned browsers may apply your default focus style to these elements when you click on them, not just if a person clicked a skip-to link), and don’t just think skip links are limited to keyboard users.

   If you have a table with hundreds of rows in it and inside the rows there are tabbable elements (like a link to a website) then your keyboard users will be very happy if you provided skip-to links on each side of the table to let keyboard users skip back and forth over the table.

   For your skip links look up Drupal’s element-invisible class to provide you with something that is visually hidden but appears when you receive focus. You can add CSS transitions to make it appear nicer than Drupal does it, but this class is based on work the Paciello Group (among others) have advocated for how to do it properly in a backwards complaint manner. I forget what they called it specifically (I work with Drupal every day so that is what I know it as, but it’s the same set of rules).

   If you’re truly interested in a11y, look at the aXe extension for Firefox and Chrome. Right now this current page has 70 issues listed — 5 related to tabindex, and 65 to color contrast.

   This all being said, the former SEO in me thinks your structure is good as it gets the real content first, but it does not like that you have the same H1 on every page and have H2 as your real page header. The a11y guy in me is not a fan of this either, but I can’t say it’s wrong. There are users that browse based on the Document Outline and that style of document doesn’t match what I would have expected, but that doesn’t necessarily make it wrong.

   I’d suggest experimenting with either (or both) NVDA (paired with Firefox), or VoiceOver with Safari. Both are free and represent two of the three most used combinations (IE with Jaws being the other, but that costs). That being said, a new WebAIM survey results are likely coming soon so we may see the popularity results change. I will say, you’ll probably want to slow down the voices as they are pretty fast as real blind users prefer things that way. Be aware, users are used to text being repeated — mostly because most sites are built poorly and no one tests for that, rather than it being something they’d like to experience. Out industry sadly hasn’t spent nearly enough education or concern for those with a11y as most stake holders only care about what they can see.

   Ultimately, do not limit your perception of those with disabilities that may browse your site. Not all disabilities result in someone using assistive technology (where here, you seem to just mean screen readers). It’s a broad spectrum and only about 30% of errors can be caught with automatic testing. That being said, if you use the automated tools to test and focus on getting a good user experience for keyboard users (that includes the various ARIA things and keyboard events you can find on sites like oaa-accessibility.org ) you likely have done a good job.

6. Thank you all for your insights! I’m headed off to bed for the night, so while people are free to keep commenting, any comments held in moderation after this will stay there until morning. (Previous commenters can bypass moderation by using the same email address used on a previous comment.) I’m looking forward to putting all you’ve shared to use!

7. Chiming in to agree with Adrian and Ashley. I wish browsers would give keyboard shortcuts to landmarks so that everyone can benefit from them, not just screenreader software. It’d be great for sighted keyboard users but also for laptops as well. Until then, skip-links can be made pretty and useful.

8. +1 to Adrian’s comments & approach.

   Looking back, I used to take the approach of content-first (early 2000s), annoyingly some research showed that screenreader users preferred the nav-first approach. My read of it was that most sites do it that way, so that’s what people got used to, even though it wasn’t optimaal. Convention (cross-site consistency) beats individual optimal solutions.

   These days the crux is that screenreaders have access to region and heading navigation, it’s quicker to navigate than with just a keyboard (like) device.

   My concern at the moment is that some people are putting the nav at the bottom for small screen devices (shown with a menu button with JavaScript), not realising the order issue it brings up. E.g. CSS day.

   I would rather it wasn’t the devs problem though, it would be better all around if the browser worked out the focus (and screenreading) order based on the flex-order, or with a basic algorythm for grids (row by row, column by column). More on that in The responsive order conflict for keyboard focus

9. Oh, short addendum: I’d add that having a skip link is still useful for folks with keyboard-only access but an see the screen. The Webaim article I pointed to is good. It would be nice if it weren’t needed, but pointing to you [main] is helpful for people who don’t have a screenreader as the browsers don’t provide keyboard access to regions.

10. +1 to Adrian’s comment about making sure that the keyboard tab order matches the visual layout. Making sure that users can focus on elements in an order that makes sense is a level-A success criterion in WCAG.

    To structure and annotate the content to raise the fewest barriers for the fewest people, I would focus on making sure that your users can jump past any blocks of content, such as navigation menus, that are repeated throughout your website (using HTML’s sectioning elements and adding “Skip Navigation” links do the job here) and making sure your navigation elements are in the same place on each webpage.

    -1 to Ethan’s comment about not being part of the accessibility hivemind. Ethan’s interview in chapter 7 of A Web for Everyone is just one example of his many contributions to a more accessible web: “For universally accessible content, Ethan urges that designers work with the native flexibility of the web, rather than trying to constrain it.”

11. These comments are gold. Thanks for sharing everyone.

12. As most things are already covered by the other commenters, I only want to add something specific to your site Eric.

    I’d advise to add role="main" on your actual main element as some older browsers (IE *cough*) do not recognize the landmark it suggests. While this is a bit verbose it helps users with combinations of assistive technology and older browsers.