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:
Why yes, I did choose a day when I met my step goal handily.
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:
It’s a little embarrassing how far back I had to look to find an activity.
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.
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.
Do we need WCAG 2.1 compliance for 508 compliance?
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.
Remember folks – I am not a lawyer, and I definitely would not depend on this blog post for legal advice.
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.
How much of this applies to me?
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.
What are these persona things?
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.
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.
This is a bit of an unfair joke, because Windows has meaningful internal version numbers, but those still skip around a bit (there is no version 7, 8, or 9) and don’t match (Windows 7 was version 6), so I feel like we can still criticize some.
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.
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.
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.
