As promised, here are the slides from my Accessibility talk at Cream City Code. Aside from the links (which, if you saw the talk, are probably why you’re here) there’s a fair amount of extra detail in the presentation notes that I didn’t have time for in the talk.
I saw people taking notes during the talk, which is great – this is stuff we need to be implementing! I’d like to particularly thank those people who actually heard me speak on this topic at That Conference last year and decided it was worth their time to come hear me again.
A div for everything and everything is in its div…
If you’ve been working on websites for a while, you’ve no doubt had a few that seem to be just div after div, where the div explosion serves to place or style each part of the page as needed. The problem is, a div by itself doesn’t tell the user (or, more to the point, the user agent) anything about what the div contains, and the styling is likely to be lost on someone using a screen reader.
In HTML5, we have the semantic elements, which generally act like divs – they’re block elements that contain other elements – but also provide meaning; each tag describes what it contains, which allows a user agent (such as a screen reader) to handle it appropriately. We still use divs, when no semantic element is appropriate, but they should no longer be the first choice. The semantic elements include:
<nav> encloses a navigation block; this will often contain a list of links, but not every list of links needs to belong to a nav. Screen readers may be able to go directly to the nav section or skip it if not needed.
<main> is for the main content of the document; it should contain only content that is unique to that document, not content repeated across multiple pages. User agents will often be able to navigate directly to the main content block, bypassing navigation links. At most one main element should exist in a given document, and it cannot descend from an article, aside, header, footer, or nav element.
<article> describes a self-contained block; it could be moved to another page and still make sense on its own. A page that consists of one self-contained block of content will simply hold it inside a <main> element, but multiple blocks that do not depend on each other will be <article>s instead. An <article> can contain other <article>s that are related to it, such as comments on a story.
<aside> contains information which is tangentially related to the primary content, but isn’t required to understand it; this content is likely to be visually represented as a sidebar or pull quote.
<figure> encloses some self-contained content, which may be (but is not required to be) graphical in nature. Each <figure> may contain one <figcaption>, which provides a caption for everything contained in the figure; this groups all of the contents and provides a way to refer to them even if the page layout changes.
<section> is a…er…section of the document; it groups together part of the document, such as a chapter. Sections generally come with headers and should contain content that logically belongs together.
If none of the above signpost elements are appropriate, then we look for a more specific element, such as <address>, <blockquote>, or even <p>. Only if the content doesn’t have any semantics do we use the plain <div>. It’s a bit more work, but it allows the user agent to process each type of content according to its own rules, according to the user’s desires.
We’ve been talking about guidelines for making websites accessible in general, and how to make them screen reader accessible in particular. Now let’s get away from the how and look at the actual impact of this work. Here are a few times when I’ve been impacted by a lack of accessibility.
Some years back, someone lent me an instructional video for West Coast Swing. The instructor was trying to explain how to dance in time with the music, and you were supposed to listen to the beat while he pointed up and down, which would have been great – except he also SAID “up” or “down” each time, so I couldn’t actually hear what he was trying to point out!
When Netflix started doing streaming video, there weren’t any captions. Many people complained (including myself) and Netflix told us that they were in the process of adding them. A few years later, they added streaming captions…for the first five seasons of Lost.
When listening to podcasts, it’s not unusual to have people sometimes speaking over music, which makes them harder to understand.
When I’ve been to conferences, speakers often show video with no captions.
In many cases, these aren’t even difficult things to fix. The dance instructor could have simply pointed rather than speaking, there’s no reason to have music on in the background when recording speech, and of course adding the already-existing captions to more of their streaming videos was well within Netflix’s capabilities if they had prioritized it. For speakers showing video, captioned versions are often available (sometimes the captions just need to be turned on!), and adding captions to original videos is fairly straightforward with modern video editing software. In each case, the problem isn’t technological; the problem is people either not thinking about the needs of viewers with hearing impairments or simply not caring.
Fortunately, things are improving. Netflix was sued under the Americans with Disabilities Act and now captions pretty much everything. Conference organizers are starting to pay more attention to accessibility. I’m in the process of booking a cruise as I write this, and the cruise ship provides assistive listening devices, sign language interpreters, and open captions on some movies. Movie theaters are now required to provide some way (usually Captiview, which is not a great option but is way better than nothing) for deaf patrons to follow what’s being said.
I’m writing this from the perspective of someone with hearing loss, because I’m deaf, but I’m sure people with visual or mobility impairments could provide a similar list of issues. What’s happening lately, partially through awareness and partially through political/legal action, is that more service providers are considering what they need to do in order for their product to be truly usable for everyone.
Ok, we get it. Banner ads are how you pay the bills for hosting your site, and the rate you can charge for them has been dropping year after year, which means you need to show more ads for the same amount of money. Which brings us to the latest trend: articles that could be all on one page, split up over 20 or 30 pages so that the user has to click next every couple of sentences (or even after one picture with a one-sentence caption).
The Page One extension for Chrome and Safari replaces the broken up pages for some popular sites with the single page version.
Stop doing this.
First off, it doesn’t work. Sure, some people are going to click through the entire article and you’ll get to show all 30 of your ads (otherwise you wouldn’t be doing this). Other people are going to click in, see the “page 1/30”, and click back. You got your one ad impression, just as if you’d put the entire article on one page, but you’ve also ticked off the user, who isn’t going to even think about linking to your content. Do it enough times, and users are likely to start actively blocking content from your site.
Second, it doesn’t work. If you’re irritating a large portion of your users this way, your click-through rates are going to drop, which means the amount you can charge for call to action banners will drop, which defeats the purpose of splitting up the article in the first place.
Third, it doesn’t work. Writing this post, I’m trying to recall what the last banner ad I saw was advertising…and I can’t. I don’t have an ad blocker installed (popups are another story); like most users, I just barely notice them. Even when I do, they’re generally either irrelevant or for something I already purchased – after I bought a cat tree a few years ago, I got advertisements for the model I’d picked (on the site I bought it from!) for the next month. Advertising can be useful to the user (and thus profitable for you) but random Google ads on a page with almost no relevant text probably aren’t.
If you have a 20,000 word article, fine, split it up into pages – that’s actually helpful in case I need to bookmark the page and come back later. But 20 words on a page? Throwing a big picture next to the words doesn’t excuse you for creating a poor usability experience.
These days, everyone wants to make it clear that they’re taking security seriously. So they make each user create a password which contains at least eight characters including a lowercase letter, an uppercase letter, a number, a symbol, and some other rule that’s completely different from every other website. Then when you can’t remember your password (I know, I know, we should be using password managers and just remembering a master password) they show you the rules and make you set a new password, which can’t be the same as a previous password. Which means that next time you actually do remember your old password…
Minimum password lengths are a good idea. Expanding the character set is probably a good idea. But there’s actually a really easy way to improve usability and not tick off your customers. If I hit the “forgot password” link? Show me the password rules! I know my own thought processes; if I know what the rules are for choosing a password on your website, there’s a pretty good chance that I’ll immediately figure out what my password is rather than having to reset it with something that’s more difficult to remember. You’re not making things any easier for hackers, but you’re making it a lot easier for users.
