While researching the WCAG 2.1 post series, I found an excellent alt text decision tree that walks you through how to select appropriate alt text for an image on the web.
If image accessibility interests you, you might be interested in the WCAG 2.0 or 2.1 post series.
The very first success criterion we’ll look at is 1.3.4: Orientation (level AA). Remember that WCAG 2.1 extends on the work already done in 2.0, so because there was nothing added to parts 1.0, 1.1, or 1.2 we can skip those. Here’s the full text of the new criterion:
Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.
This is one that definitely feels like a best practice in user experience. Let’s take a look at an the Garmin Connect app, which both follows this standard really well and really poorly at the same time.
Here’s one of the screens showing my steps for the day on my phone:
When the phone is in portrait mode (the way most of us hold our phones most of the time), everything looks good, although the astute reader will note that app violates success criterion 1.4.1). But here’s what happens when we flip that onto its side:
When we’re in landscape (the way most of us should shoot videos on our phone), everything is sideways. It’s, honestly, terribly annoying, if not a little lazy. If those boxes were to all rotate with the screen, and maybe just be oriented a little differently, the screen would be just as useful, and provide the exact same information.
But the connect app also does a good job taking advantage of the different screen orientations to show different information. Here’s another example from an activity a while back:
But this time, when we switch to landscape, we get a different screen:
The developers over at Garmin clearly felt that those graphs only make sense in landscape, where they can be a larger while maintaining proportion. I’m not sure I fully agree – sometimes activities are so long you need a monitor, not a phone – but they clearly feel that the specific screen orientation is essential to the information being displayed.
If you’re leaving out screen orientation as a part of your media queries when developing for the web, then you’re probably in good shape. And, on the topic of good shape, feel free to send me a step challenge on Garmin Connect. I’ve got a camping trip coming up this fall, and for once I’d like to huff and puff less than the other folks with me.
Looking for the rest of the posts in this series?
At the beginning of the month we changed our normally static homepage to include the following animated gif:
We tend to swap the homepage image to be an animated gif about three or four weeks before classes start, and link it directly to our registration platform. While these images can be pretty, after you’ve watched them for a couple of minutes, they start to feel really annoying. And, invariably, after a week or so, the first complaints show up. But here’s how we respond:
Those images drive hundreds of clicks in the weeks after we launch them. So, annoying or not, if they’re achieving their objective, that’s what’s important, right?
But then we got a complaint email that wasn’t about the image being annoying, it was about the image being distracting. And that got me thinking – they were probably right. Motion can negatively impact people with various cognitive impairments.
Before we go into how we responded, let’s talk a little bit about why we’re using a gif. I mean, the gif format is 30 years old. Almost everyone has moved on to web video. But when we launched the updated website, we were stuck supporting all the way back to Internet Explorer 6. And for Internet Explorer 6, 7, and 8, there was no non-flash video option. So we build the website with support for images, but often not video (though we’ve been adding some support, it hasn’t been across all parts of the site).
Stuck with gifs, I tried to resolve this as quickly as possible, since there was someone out that I knew was negatively impacted by the image. I quickly skimmed the WCAG 2.0: 2.2.2 standard, but it turns out this one is a little more complicated than I first thought. Here’s the full text:
2.2.2 Pause, Stop, Hide: For moving, blinking, scrolling, or auto-updating information, all of the following are true: (Level A)
- Moving, blinking, scrolling: For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and
- Auto-updating: For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.
On a first read, I assumed this success criterion didn’t apply. After all, there’s no moving, blinking, or scrolling information. Leaves are moving, but text is not. But, as many high school teachers I ignored told me, always read all of the instructions.
My first thought was to do some searches and see if I could find a way to quickly add a pause button to animated gifs, since that would be an easy, site wide fix. I was definitely reaching here, but it turns out it’s a somewhat viable option. This solution involves creating a png of a single frame of the gif, and swapping them on click. That felt problematic to me. While it might work if you click to pause the image, because our image is linked to our registration platform, I’d need to add an actual button over the image somewhere. That can be rather involved, with making it cross-browser, all screen size friendly, and ensuring it’s sufficiently accessible itself.
With the button ruled out, I thought that the easiest thing we could do would be to just remove some complexity from the image. We could make the leaves go slower, and maybe remove a few leaves. After a bit of work, our student designer put together this image for us within a few hours of the initial complaint:
That image has about half as many leaves, so it’s a lot less complex. And the leaves stay off the screen for a bit, meaning there’s always time without motion on the screen.
But while I was able to confirm the reduced complexity image solved the problem for our user with the complaint, I couldn’t shake the feeling that I really ought to read the entire standard.
It turns out that if I’d just scrolled the page down a little bit, I’d have seen the information in the very first sentence. Here it is:
The intent of this Success Criterion is to avoid distracting users during their interaction with a Web page.
While I still think the success criterion needs some edits to be more clear about what constitutes “information”, certainly the purpose of the standard is to reduce distraction. And both Penn State and WebAIM agree: animations need to be very short or user controllable.
The next easiest fix was to turn off looping on the animation. That way there’s still enough motion to capture attention, but not enough to distract. Here’s what we came up with:
Of course, there’s some some downsides. For instance, say you embed a gif halfway down a page, and it takes more than 5 seconds to scroll there (like this page! If you’re not seeing motion, reload the page and scroll quickly). The visitor will never see the animation (note – this is fixable with lazy loading of images, but those weren’t a thing when we built this site, and we’ve had trouble grafting them on). But for us, with the image essentially at the top of the page, it’ll probably work. This also doesn’t work for cinemagraphs, which depend on perfectly looping images to create the effect of slight motion in an otherwise still world.
After we had an actual fix in place, we did a quick check across the entire site for other animated gifs, and found only one other place where there was a problem. That image has since been removed completely.
We’re currently exploring finally adding video support for some of the last areas of the website that don’t support it. Video would not only provide a way to pause animation, it would also allow for much higher resolution images and more complex animations. But fitting video into pages is also more complex, and if we’re unable to find a way to do what we need without a lot of work, we might end up waiting for the next iteration of the website. More details on that soon!
A few years have passed since our last accessibility series, and since then, the W3C has published the new WCAG 2.1 standard, which has further complicated the digital accessibility landscape. This post will dig into why things are a little more complicated and then, much like last time, future posts will explore what we can expect from WCAG 2.1. I’ll keep this post updated with links to the future posts, so check back here if you’d like a table of contents to all the entire WCAG 2.1 series.
No. But.
Creating federal standards is a fairly involved process, and the official 508 standard is likely to lag behind for some time. However, the actual digital accessibility compliance landscape is a little more complicated, and it’s likely only a matter of time before WCAG 2.1 becomes a commonly accepted digital accessibility standard, and we start seeing case law referencing WCAG 2.1.
But beyond that, we shouldn’t be thinking of accessibility strictly as a compliance issue. We also need to be thinking about open access for everyone. And some of the new rules, in my mind anyway, aren’t just good accessibility practices, they’re good user experience practices.
For the foreseeable future, Lane will continue to use WCAG 2.0, level AA as our official accessibility standard. But that doesn’t mean we can’t start thinking about what’s coming, and implementing best practices where we can.
WCAG standards aren’t just for website builders, they’re also for anyone who develops digital documents, like PDFs, Moodle courses, online quizzes, or graphics for display on our digital signs. While many of the changes in WCAG 2.1 are on the technical side, there are some that almost certainly apply to you. I’ll make a note on each entry in this series I think is more broadly applicable to people who work outside of web development.
When developing the 2.1 standard, the W3C developed personas through which they could view different problems. You can think of a persona as a pretend person, with a set of needs that could be a real person’s. For instance, as part of the upcoming website redesign, we may develop a persona like this:
Alice is a recent retiree who is interested in using her newfound free time to explore her long dormant artistic interests. She feels confident about using a computer, but she’s a little nervous about how long it’s been since she took a course in school.
There isn’t an Alice, of course, but there are people like that out in the community. Contrast that with Bob:
Bob is a high school senior, who hasn’t considered what he might want to do for a career, but knows he’ll be attending Lane in the fall. He isn’t terribly interested in school, and mostly does things when his parents prompt him.
Clearly Bob and Alice are going to use the website a little differently. With website design, the problem is how to make one site that works for both of those people. For the W3C, they used personas to explore how different, specific impairments could impact technology use. For each of the criteria in the WCAG 2.1 standard, I’ll try to include the persona that the W3C used, since they really help to illustrate just who this standard is going to help.
The W3C provides a comprehensive list of personas they used for WCAG 2.1.
In the software engineering world, many software projects use a practice called semantic versioning to illustrate the magnitude of differences in a new software release. The first number is typically the major version number, followed by a dot, and then a minor version number. Sometimes that will then be followed by another dot containing the patch number, or other information. When the major version is incremented, that usually means that the changes were so great that they broke how things were done in the past. When the minor version is incremented, that means new functionality was added, but nothing was added that would have broken how things used to work.
For instance, Slack on my computer is in version 4.0. From that, we can determine that Slack is yet to add new features to this release of their software, but they’ve made several major releases and rewritten quite a few things. On the other hand, right now my parents are using WhatsApp to ask me why I haven’t bought planet tickets home for the holidays yet. WhatsApp is currently in version 0.3. The leading 0 seems odd, but typically is thought to mean that the software is still in some sort of test version, even if the whole world is using it (much like how Gmail was in beta for 5 years). The 3 means that WhatsApp has put out three updates which introduced new functionality, but didn’t break things.
While that might seem confusing, it’s worth reflecting that it’s a lot better than certain other software projects, which used the version numbers 1, 2, 3, 3.1, 95, NT, 98, 2000, ME, XP, Vista, 7, 8, and 10.
In the WCAG world, you can see that when they moved from version 1.0 to version 2.0. The changes were so great that the rules from 1.0 wouldn’t apply anymore, and could just be thrown out. WCAG 2.1 is a minor release. Rather than replace WCAG 2.0, the 2.1 standards extend the 2.0 standards, and give us new ways to ensure our software is accessible.
The UK Government Digital Service has published a great set of posters about designing for accessibility. They’re a great reminder that designing for accessibility isn’t just about screen reader, but about designing for a lot of different conditions that impact a lot of people.
We all know how to make an image accessible. And we all know how to make a link. But how do we make them play together? How do we do something like this:
Since we’re good people, we add alt text describing the image, right? Maybe something like “Graphic Standards Cover”? That’d give us (overly simplified) HTML like this:
<a href="standards.pdf"><img src="cover.png" alt="Graphic Standards Cover"></a>
But that’s actually not so great for accessibility. A screen reader will read “Graphic Standards Cover”, which doesn’t make the action (downloading the standards) clear.
My first instinct was to add a title to the link. But the title is almost never read by a screen reader, and may even make things worse. The reader will read the alt text. To make it clear what the link does we need to change the alt text:
<a href="standards.pdf"><img src="cover.png" alt="Download the Lane Graphic Standards"></a>
Now we’ve solved the accessibility problem, but we may have created a user experience (UX) problem. Scroll up a second and look at that image again. Did you know that you should click that picture to download the PDF? Or did you think it was just a picture? We can’t even rely on people discovering the picture is linked by hovering over it with the mouse and the cursor changing: it isn’t possible to hover with your finger on a phone.
Sometimes it may be immediately clear that a picture is clickable from context. If it isn’t we may need to add some help:
<a href="standards.pdf"><img src="cover.png" alt="Download the Lane Graphic Standards">Download the Lane Graphic Standards</a>
Now we’ve solved our UX problem, but we’re back to an accessibility issue! A screen reader will read the alt text and the link text. It’ll be like the same sentence is printed twice. The solution to this is to have explicitly empty alt text:
<a href="standards.pdf"><img src="cover.png" alt="">Download the Lane Graphic Standards</a>
Explicitly empty alt text will be ignored by the screen reader entirely, while missing alt text can cause unpredictable or even negative behavior.
You could also go back to adding descriptive text as the alt text. In our example above, that isn’t appropriate, since the cover is really just decorative. But consider another example:
That image is linked to the full size picture. Describing the contents of the picture is completely appropriate. But remember that most screen readers can pull links out of a page, and let someone navigate from link to link directly. For that reason, our alt text is “A cat chewing on a monitor. Link opens a larger image.” The alt text serves double duty.
This post does not, of course, mean it’s always appropriate to use an image. It’s important to avoid off-brand or inappropriate images. It’s important not to add so many linked pictures that your page hierarchy gets lost and navigation gets more difficult. And if something can be done in CSS, it probably should be. It wouldn’t hurt to use images as pictures as rarely as you can.
If you’re not sure what to do with links at Lane, get in touch! We’re always happy to help.
An instructor asked me the other day, “How does a screen reader read text in ALL CAPITAL LETTERS?”
I didn’t know, and through it was a great question, and had to figure it out. Let’s start with some sample text:
It’s VERY important you remember these:
- USPS
- NASA
- DVD
There’s four words in all caps there. Let’s look at each one, from the bottom to the top:
DVD is an initialism, meaning you read each letter in it, like CPU or FBI. NASA is an acronym, meaning you read it as a word, even though each letter stands for a word. USPS is another initialism. But VERY is just a word, with all capital letters being used for emphasis.
Of course, it’s wrong to use capital letters in this way – you should instead be using an em or strong tag (though which one is complex, and I didn’t find the examples in the specification very helpful). But the instructor’s question wasn’t about what should happen, it was about what does happen. How can a screen reader know which of those words it should treat as words or acronyms (which are like words, in terms of pronunciation), and which it should treat as initialism (and read letters instead of the word)?
I ran each of the examples through the say program on my Mac, and here’s what I got (sentence case was pronounced like lowercase):
| Word | Uppercase | Lowercase |
| Very | word | word |
| USPS | letters | word |
| NASA | word | word |
| DVD | letters | letters |
There’s some interesting logic there. I think this table shows my Mac will always read dictionary words as words (like “very”). And I think it shows that my Mac also has a list of known acronyms and initialisms, so it knows how to read those. For words that aren’t in either list, but also aren’t in the dictionary (like USPS), it reads all capital letters as initialisms, but lowercase as a word (a reasonable assumption, since most of the time it encounters words that aren’t in the dictionary, it’s probably due to the lang attribute not being set correctly.
Of course, this is just say on my Mac, which isn’t even a screen reader. WebAIM has some general rules for how screen readers read things, but it isn’t really predictable how a screen reader is going to pronounce words in all capitals. Pronouncing typographic symbols is hit or miss as well — some, like @ and % are read correctly. But most others (like the parenthesis, or the mdash in the previous sentence) aren’t read universally. Rare punctuation, like the interrobang (‽) may not be read at all.
I was hoping that abbr would influence how screen readers pronounce words, but that doesn’t appear to be the case (and, if you’ve been around HTML for a while, remember you’re not supposed to use acronym at all — though it probably wouldn’t do anything here anyway).
What does this mean for you at Lane?
Use the abbr tag to specify acronyms and initialisms if possible. Even though screen readers won’t necessarily change how they handle pronunciation, abbr with a title attribute makes it easier for anyone to understand meaning. Try hovering over this: NASA.
If you want to use capital letters for emphasis: don’t. Instead, use either an em or a strong tag, depending on if you’re trying to emphasize something or make it note that it’s more important than surrounding text. And, of course, never use strong in place of a header.
If you want to use capital letter for aesthetic reasons, then you should use a bit of CSS to make it happen:
.all-caps {
text-transform: uppercase;
}
Screen readers ignore CSS, so this use is entirely for presentation. Just make sure you don’t confuse presentation with meaning.
I ran a quick search on our website for pages that have a lot of capital letters all in a row:
SELECT entity_id
FROM field_data_body
WHERE body_value REGEXP BINARY '[A-Z ]{10}';
There were 748 results. Editing 748 pages obviously won’t happen overnight, and on each one we’ll need to determine if we should instead be using a header, a strong, an em, or just normal text. For now, I’ve queued a task for us to tackle in the future, but if you’re editing your page and notice some misuse of capital letters, we’d be forever appreciative if you’d fix it.
The last standard we’ll explore in our series on understanding WCAG 2.0 is 4.1.1 Parsing. This standard is required for WCAG level A compliance, which is part of what Section 508 requires. Here’s the complete text:
4.1.1 Parsing: In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. (Level A)
Web Browsers operate under a forgiveness by default principle. They’re very liberal in what sorts of input they accept, and they do their best to show you something. Here’s an example, taken straight from that link:
Hello!
If you inspect that line, you’ll find the color is specified as “sxbxxsreen”. “Sxbxxsreen” doesn’t exist as a color, either in the real world or within the browser. While most computer programs would either ignore “sxbxxsreen” or crash, browsers make a guess. Firefox converts the whole thing to a set of rgb hex values, using 0’s for invalid characters (look for Dak’s comments in that link for full explanation). Not every browser guesses the same way.
Web browsers also guess with malformed html:
<title>hello</title> <p>Hello! <body bgcolor="sxbxxsreen">
There’s no doctype, no html tag, no head tag, the p tag isn’t nested properly and doesn’t close, the specified background color doesn’t exist, and the body doesn’t close. But, amazingly, my web browser renders that page without complaint:
While this is generally a good thing (nobody really wants a browser to stop working because of a minor syntax error), it can become a problem if we depend on browsers to always guess correctly. A screen reader, which is a type of browser (though the WCAG specification refers to both browsers and screen readers as “user-agents“, I’m calling them browsers in these posts because user-agent has another meaning). And while most of us test our web pages to make sure they work in the most common browsers, none of us has every browser out there.
This standard requires four things: close open tags, nest tags correctly, don’t use duplicate attributes, and make ids unique. The easiest way to see if you meet those requirements is by validating your page. To do that, first make sure your doctype is correct, since that will tell the browser how to interpret the html. In older pages, you might see something like this at the very start of the source:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
But most new web pages use the HTML5 doctype:
<!doctype html>
which is the first and only doctype I can write from memory.
One your doctype is correct, you can use the W3C validator to check your document for errors. Here’s links for the legacy validator and the HTML5 validator.
If we validate the Lane home page, we’ll find many errors and warnings that don’t relate to the WCAG standard, and which we’ll have to interpret ourselves. For instance, there’s these:
xmlns:video not allowed here.xmlns:product not allowed here.xmlns:content not allowed here.xmlns:dc not allowed here.While technically these attributes aren’t supposed to be there (since they’re XML namespaces and not part of the HTML5 specification), none of them are duplicate attributes, so they’re allowed according to the WCAG 2.0 standard. This page also has a bunch of warnings. Some of them we can also ignore, but others are spot on:
Without any doubt, I should fix those three warnings. But note what this validator didn’t find: missing tags, improper nesting, repeated attributes, or duplicate ids. In other words, this page meets this standard, even though there’s some work I should do, and even though it doesn’t technically validate.
If you’d like to know more about this standard, check out these examples and techniques.
Interested in more? Check out the listing of all the posts in this series.
The next standard we’ll explore in our series on understanding WCAG 2.0 is 3.3.4 Error Prevention. This standard is required for WCAG level AA compliance, which is part of what Section 508 requires. Here’s the complete text (it’s a long one):
3.3.4 Error Prevention (Legal, Financial, Data): For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true: (Level AA)
- Reversible: Submissions are reversible.
- Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
- Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.
Here’s the idea: sometimes users, especially those with disabilities (and me, as you’ll see in a minute), submit forms either by accident or without fully understanding what happens when the form is submitted. Imagine, for example, someone with motor control issues who accidentally presses enter early while filling out a form, submitting it. This standard asks us to make sure that one of the three things in that list applies to the form.
There are a number of circumstances where we don’t need to do anything at all. For example, say we have a web form in our ERP that lets us set an address. As long as changing the address again is easy (for example, by filling out the form again), and we’re shown what the new address is after submission (either as a confirmation, or just with a page reload on submit), then we’re in good shape.
But we need to look for web forms that are not easily reversible. For instance, let’s look at a situation which may or may not have happened in my life about ten years ago. I was trying to pay a bill online. When paying it, I misplaced a decimal point, and paid ten times as much as I owed (like this: $3000.0). The system processed my payment without complaint, overdrawing my checking account, bouncing a $2.00 check at the library, and leading to so very many bank fees. A simple confirmation page (which, to be fair, they’ve added), or even better, a confirmation page that warned me my payment only had one 0 after the decimal point, would have saved me a lot of grief.
What’s tricky about this accessibility requirement is that most of us rely on third party services for these kinds of legal, financial, and data programs. We buy our ERP system and payment processing systems from vendors, rather than create them at home. Even though we’re not doing development ourselves, we’re still responsible for ensuring our systems are complaint. If your system is receiving updates, and compliance won’t be available by January 18th, 2018, you may need to file a bug with your vendor.
If you’d like to know more about this method, check out these examples and techniques.
Interested in more? Check out the listing of all the posts in this series.
The next standard we’ll explore in our series on understanding WCAG 2.0 is 3.3.3 Error Suggestion. This standard is required for WCAG level AA compliance, which is part of what Section 508 requires. Here’s the complete text:
3.3.3 Error Suggestion: If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content. (Level AA)
This standard has to do with input validation. Let’s say that we have a webform, like this:
This standard is all about what happens when you enter the wrong thing. Say, for example, we enter “9740” as our zip code. This is the wrong way to tell the user:
Wrong
To meet this standard, all you need to do is provide a helpful error message:
Please make sure your zip code contains exactly five numbers, then resubmit the form
Of course, you don’t want go to the other extreme, either. Think about this nightmare:
Invalid Password. Your password must meet the following rules:
One of the goals of this standard is to help people with cognitive disabilities. Yes, that error message explains all the possible circumstances that could have caused the error. But the suggestions aren’t helpful — you have to work to figure out which rule you violated.
And that’s it for this standard. If you’d like to avoid the the messy details, you’re welcome to just skip to the end. But this post got me thinking. When you’re making a form, labels are associated with form fields via the for attribute on the label and the id attribute on the field. That way a screen reader knows how to associate labels and form elements. But how does that work with an error message? There’s no for attribute for an error message. Right?
The first place my research took me was the WebAIM site, which suggests a two part approach. First, error messages should be listed at the top of the form. Second, each error message should link to the associated input element. So our form would look like this:
Please make sure your zip code contains exactly five numbers, then resubmit the form
This method meets accessibility requirements, but fails from a usability perspective. If we were to expand that form to have several fields, then visually associating error messages and fields would be difficult. The best practice is to instead display the error message next to the form component it applies to, like Twitter does:
But that leads us back to linking the error message and the form component. WAI-ARIA provides a way to do that:
Please make sure your zip code contains exactly five numbers, then resubmit the form
I know that looks pretty much exactly the same, but I promise if you break out your developer tools, there’ll be some extra attributes. First, we need to add aria-invalid=true to the input (depending on your error, there are some additional attributes you can use). Then, we add the aria-describedby attribute to the input and have it point to the id on our error message.
If you’d like to know more about this method, check out this page on WAI-ARIA regarding form validation. Or, if you’d just like to know strictly what WCAG 2.0 requires, you can look at these examples and techniques. Specifically, be sure to check out the technique for using aria-required to indicate a required field – just putting a * next to each field isn’t good enough. This blog post provides some additional examples and advice.
Interested in more? Check out the listing of all the posts in this series.