What responsive web design can learn from accessibility best practice
This is a presentation I gave at the Web Directions Respond 2014 conference in Sydney on February 5th 2014. A link to a downloadable PowerPoint version is provided at the end of this post.
Hi, I’m Adem, I’m an accessibility specialist, and today I’ll be talking to you about what Responsive Web Design can learn from accessibility best practice.
Responsive design as I understand it is all about flexibility, and to kinda paraphrase from Ethan’s book (Responsive Web Design),
it’s about creating “…sites that are not only more flexible, but that can adapt to the media that renders them.” — Ethan Marcotte – Responsive Web Design
To me, if I was to define it, accessibility means providing universal, barrier-free and equal access to the web, and technology in general, for all users, regardless of ability, disability, browsing device or location.
So, like responsive design, accessibility is based around that same concept of embracing flexibility.
Adopting accessible and inclusive design practices can help produce more effective responsive designs.
And throughout the rest of this presentation I’ll giving you all some tips, as I prove that point.
Ok, so Zoom. The ability to zoom is extremely important to visually impaired / low vision users, who rely on the ability to engage text to be able to read the content.
We all surf the web on the train…., we use our phones, and we use our tablets. And I’m almost 100% sure that at one point or another we’ve all zoomed into something while using our devices on public transport. We’ll be wanting to look a bit closer at an image, or just make the text of a blog post that little bit bigger.
And I’m guessing that like me, many of you don’t consider yourselves visually impaired, just because you use the zoom, you just like being able to zoom into things when you need to…
And how annoying is it when that doesn’t work, when you can’t zoom in? I have to say, this is one of my pet hates, if I get to a page, need to zoom in and I can’t I go somewhere else…
Being able to zoom in on things is not only an accessibility requirement, it’s also great when you’re reading something on a small screen and need to make things a bit easier to see.
Following on from zoom, I’m sure we’ve all heard the term “Progressive Enhancement”. You’ve got a basic implementation of a site that works across most browsers, devices, and with a wide range of assistive technologies, and you add interactivity or enhance functionality when it’s supported by the device or browser being used.
I’ve used a non web example here, because I think this quote illustrates it quite well:
“An escalator can never break: it can only become stairs.” — Mitch Hedberg
they still work when the technology fails or there is a power outage, they’re just a bit less convenient to use.
Similarly, with progressive disclosure, you show only the information necessary at that point in the interaction. You separate information into multiple layers and only present layers that are necessary or relevant to the task being performed.
The means less clutter, and a website that is easier to understand and navigate.
We’ve all seen how twitter does this, they start with your feed, that has an expand link under each tweet.
By clicking that link, you get a timestamp, numbers of people that have retweeted you and a text area where you can compose a reply.
From an accessibility perspective, this is particularly good for people with cognitive impairment and vision impairment. And I know of people who’ll use the mobile versions of sites exclusively, because they find them easier to navigate and interact with.
Colour contrast is one of those things that people may not necessarily think about, but it can make a real difference to the effectiveness of a design.
We can be on the web anywhere these days, using any number of devices. You could be on your phone, your tablet, even your smart watch.
Now, if we take a look at the image, we’ve got it split in half, with someone using their iPhone to view a site while indoors on top, and someone viewing the same site while outdoors on the bottom.
While the contrast of this site is quite good, and things are still readable, if we look at the outdoor section it’s clear that the contrast has been lowered.
You could be in many different situations while browsing on your phone, an area of high light, or low light, indoors or outdoors or going through a tunnel on public transport.
In any of these situations, not having good colour contrast could make content hard, if not impossible to read.
Consistency and predictability is your friend
The easier it is for someone to use a website, the better their experience will feel. The visual design of elements should make it easy for a user to understand how to interact with them.
Simplest way to explain this is probably to talk about links. There’s no point in designing something flashy to act as a link, if no one understands it’s a link.
People expect links be underlined, or appear as a button, a tab, or some other type of obviously actionable element.
What we’re aiming for here is… Woo Hoo!
We want the user to enjoy our websites.
What we don’t want, is…..
That DOH moment, we don’t want people leaving our sites because they can’t operate our interfaces.
What I’m saying here is to basically to stick with what works, don’t re-invent the wheel. There’s no need.
Standard controls are keyboard accessible & touch friendly
I’m sure we’ve all encountered something similar to what’s in the screenshot. You’ve got the standard HTML select box, how that’s displayed on an iPhone and how it’s displayed on an Android device.
And here you’ve got the standard HTML select box, and a version from one of the UI frameworks.
And you’ve probably all heard that an important thing from an accessibility perspective is to make sure that things like form controls, navigation are usable with a keyboard.
But you may not know, that using the standard HTML elements for select boxes, buttons etc gives you cross device, cross platform accessibility for free.
Because standard controls inherit the native accessibility features of which ever platform they’re being used on. That means a lot less development work, as the interactions have already been implemented.
Touch, Keyboard, even screen reader the standard controls will work.
And I’ve got a demo of the standard HTML select vs the UI select box, recorded on my Galaxy S4 running Android 4.3 using Firefox.
So, as we’ve just heard, for the standard control, all the options are announced, and the fact that the control is a combo-box is clear.
Whereas with the UI framework version, as we heard was Mustard button, which provides absolutely no context that there are any other options available.
Who’s seen something like this before?
You’ve just done a search, or you’re moving through a list of products and when you get to the bottom there’s the list of linked page numbers you use to move through pages.
Now I’ve got fat, ‘homer like’ fingers, and as hard as I’ll try, there is absolutely no way that I’ll be able to hit the number I’ll be aiming for, not at that size, and such a small space separating each number. No chance.
Sometimes text can be big enough to read, but too small to touch. Larger touch targets are important to make sure that people don’t hit the wrong thing, and especially important for those dexterity problems or who cannot see the screen.
If you’re using something live VoiceOver on the iPhone, you move you finger around the screen as it reads what’s underneath it, you tap to select, and then you double tap to activate what you’ve selected. So if you haven’t got enough space between targets to select the right things it’s going to get quite frustrating quite quickly.
Thinking mobile first is a good solution to this problem, because you start by thinking of targets in terms of touch first, before moving to desktop interactions.
An accessible, standards based foundation makes doing responsive easier!
Let’s take another look at my definition of accessibility from earlier, “providing universal, barrier-free and equal access to the web, and technology in general, for all users, regardless of ability, disability, browsing device or location” and focus in on the “browsing device”.
This could be a web browser on a desktop PC, it could be a bowser on your phone or tablet, or it could be a screen reader or a screen magnifier. It doesn’t matter, if the foundation of your site is built with web standards, if you’ve used properly structured and semantic mark-up, your content can “respond”, it can “adapt”, and it can be flexible to the needs of the user, regardless of the device they’re using or the context they’re using it in.
That’s it, thanks for listening.
Download PowerPoint slides
You can also Download the PowerPoint slides to this presentation. Note: I’ll be making accessibility updates to the PowerPoint version over the next couple of days.