Moved Photos Restaurant Airports “Blind” When I make websites, I think about Mike.
Mike looks very thoughtful in all the photos I have of him, starting wistfully off into the distance, mostly because he can’t see the camera. Restaurant. Airports. Mike never uses the world blind, I knew he couldn’t see very well but I didn’t actually know he was blind until he used CNIB card to get me a free train ticket as his “escort”. When I make websites, I think about Mike.
Define common tools a11y tools
Web accessibility is a catch all term for the stuff we can do to make it easier for people who use different tools to access the web. Instead of the tools we take for granted like: a monitor, a mouse, or a keyboard they may rely on tools like screen readers, voice recognition software, high-contrast plugins, or trackballs.
Let’s look at five examples of assistive technology and then I’ll talk about what it means to build an accessible website, and how that makes your site better for all your users.
Define Really fast Read example Scanning (heading/link)
Background Color Turning this…
…this. Different Customizable
Different high contrast themes work differently. I’ve seen ones that makes the links a rather alarming shade of green and of course the users can customize them from here if they want.
Explain Page up/down Keywords
Voice recognition software lets the user navigate using a series of predefined verbal commands. “Page up” and “page down” are pretty straight forward but it gets more complicated when the user wants to click on a link or a form element. Some software will allow the user to navigate using keywords. For the top story on the BBC home page we could say “Russia” and if that’s the only story about Russia on the page we’re go to go. If there’s another link with the word Russia the links get numbered and the user can identify the link by number.
To click when there’s no clear text prompt the user can divide the screen into a grid and work their way in. So a one on the opening grid would focus the grid on one section of the screen.
Refine Course Pointer.
To click on the top story we’re in good shape now but to click on News instead of Sport then we would have to refine the grid again.
This is an example of we call a coarse pointer. It’s a term you might have heard before to describe fingers on touch screens. The opposite of a coarse pointer is a fine pointer which is what we get with a mouse which is accurate to a single pixel. That doesn’t mean the person using it can be that accurate though
Explain Pointer keyboard
Trackballs separate the act of clicking the mouse buttons from moving the mouse. They’re intended for people who don’t have fine motor control so that they don’t move the mouse by accident while they’re trying to click on something. Like voice recognition users these users can find it hard to to hit a small target and trackball users may also struggle to use a regular keyboard.
Some users only use a pointer. Other users only use a keyboard - navigating the page by paging up and down and tabbing between elements. Like those with touch screens these users are incapable of hovering over an element on the page.
- youTub Try it
If you’re interested in seeing any of these technologies in use there are lots of good youTube videos you can watch to see an expert at work.
And if you want to play with how any of these work yourself there are lots of free plugins and trial versions available for download.
Stats Impact. Raise hands Make a difference. What does it mean? 4 things
You may be wondering how many of your users depend on these technologies but it’s hard for us to get statistics on it. For the most part these technologies are invisible to our analytics but let me give you some idea of the impact you can have.
Raise your hand if you know someone who is: Blind, someone with MS, ALS, Cerebral Palsy, Muscular dystrophy, arthritis, Parkinsons, someone deaf, someone colour blind, someone with dyslexia, or someone who’s had a stroke.
I have 3 hands up now. Look around. (hands down) I like to think we all got into web design to make a difference…. This, right here, is, this is our chance! Think of the difference it makes to someone who can’t read labels, talk on the phone, or walk around a store be able to come to your site and find an easy way to shop, apply for a job, message their friends, or whatever it is your site does.
So what does it meant to build an accessible website? Well, to have a truly accessible website 4 things need to be done well:
#1) User Experience Design. We need to have well organized content, good information architecture, and clear interface design.
Basically, if your users can’t find what they need when they can see and hear all of your site, nothing a developer can add will make it any more accessible.
A solid foundation of semantic HTML is necessary for accessibility.
Semantic is the technical term, what we really mean here is meaningful markup.
When making accessible sites, this is the area that people typically focus on first. Lucky for us this means that the W3C got a bunch of experts together and created an acronym.
The Web Content Accessibility Guidelines are a bunch of really basic things I hope we’re all already doing but because they’ve all been written down in once place there are now handy check lists and validators we can run out sites through. I’m not kidding about how basic these rules are. They’re things like: use heading tags for headings, put your links around descriptive text, and use an actual submit button to submit an actual form.
If the first time you heard the term accessibility applied to the web was today, your homework is go home and run your site through the evaluation tool at wave.webaim.org and start by just reading and understanding the changes it wants you to make.
WCAG is the first people think of when they discuss accessibility and where there are laws mandating accessibility they reference the WCAG. I wish I could tell you…
By itself semantic HTML is very accessible. If you’ve done a good job making sure your content makes sense without visual formatting all you need to do with CSS is just be careful not to screw up that accessibility when we add our presentation layer.
Begin by styling the right element. If that h3 needs to look like an h2, make a class to apply the style, don’t change the HTML to make it easier to style. THIS GOES DOUBLE, TRIPPLE, QUADRUPLE, FOR FORM ELEMENTS. Browser makers have done a lot of work making form elements accessible and you lose all that if you try to make your own from scratch.
You can also use CSS to make small improvements like providing icons with text fallbacks, large hit areas for course pointers, and hiding visual flourishes from screen readers by moving them into generated content because > doesn’t sound like a right arrow even if it looks like one.
Also, give users control over videos and animations. Flashing or moving page elements can cause trigger seizures or vertigo for some people, they can be a distraction for users with learning disabilities, and they can just really annoy other people.
Semantic HTML isn’t always enough to communicate what we’re doing to screen readers, and for those users specifically the W3C has created a set of roles and attributes you can add to your HTML to make make it clear-er to screen readers the purpose of different elements on the page and how they interact with each other. These are called ARIA roles and and attributes.
If you make small brochure sites you can learn most of what you need to know about ARIA in 2 hours, if you make apps with complex functionality give yourself a little longer.
Me travel Intro Steve Detail phone
This is Steve. I met Steven when he was running what was best but inadequately described as an agency. When I decided I was going to go freelance and travel the world Steve was the first person to give me work… and the second… and the fourth… and the fifth… and the seventh. In fact it very quickly be came clear that there was a place for me at his company and Steve talked his business partner into hiring me even though I was on the verge of moving to the other side of the planet.
Steve was impressed by my attention to detail. He liked that I did things like adding icons to alert messages or insisted on displaying error instead of just putting a coloured border around a from field. Steve knew, if you can count on someone to get the little things right, you can count on them to get the big ones right too.
Steve was the kind of boss who takes a turn answering the support phone on weekends. Which is how I found out that he’s colour blind.
One Monday I came in and he was on the phone with a client’s hosting company giving them unsolicited web design tips. Our client’s site had gone down over the weekend and in the process of tracing the problem Steve visited their website looking for a list of which of their servers were up and down.
This, more or less, is what Steve saw. Well, one of their servers is having issues. Or maybe it’s two? It’s not really clear when you can’t see the colour.
Steve is in good company… 10%…
This is not the real hosting company website, of course. I’ve changed the code to protect the guilty but also because I want to use it as an example.
Oh fictional hosting company. You’re really terrible at front-end development. Not inline styles terrible, but I’d still fail you.
Let’s see what we can do to make this code better.
This list of server details should really be a list.
This text at the top here, that identifies what comes right after it. That’s clearly a heading.
What is this? It seems to call itself a button but… it’s not really a button.
It’s in a span tag.
but even if they could get focus our user couldn’t tell, because there are no focus styles defined so they wouldn’t know when to “click”
Let’s fix that button.
First we’ll make that span into a button element. Whew, that feels so much better already.
There’s different types of buttons and IE gets finicky if it can’t figure out which kind we mean, so we’ll be specific.
And what do we do about our CSS? Well, now that we’re using a button element the browsers automatically apply an outline to the button when it gets focus. (blue/dotted) But let’s assume our client complained because that’s cuz its ugly and asked us to remove it. NEVER REMOVE FOCUS STYLES. Nope, don’t do it. If you don’t like them *design better ones*
Providing an alternative is easy though, let’s just duplicate the hover styles. Done. Well, almost. The only indication that we’re interacting with this element is a change in background colour and text colour. Remember that a high-contrast theme will over-ride background and text colour declarations - leaving these users without any indication that they’re hovered or focused on the element. I’m just going to add an underline in there for them.
What else can we do to fix that button?
Well, D-E-T-A-I-L-S will be read out by a screen reader as if it was an acronym, so let’s make that lower case, we can uppercase it again with CSS in a minute.
And there’s a weird unicode character there, I’m not sure what a screen reader will do with that either but it’s a presentation decision, so let’s remove it from the HTML and move it into the CSS.
Actually, you know what? This button isn’t really about details at all. This button is all about the server.
Let’s remove the “details” and the weird unicode character all together and replace them with the server name.
And instead of keeping the button styles on that little grey button. I’m just going to make that button take up that entire line.
To help you visualize it, you can pretend I just did this. Though after we apply the classes…
Moving the styles from the h3 to the button
… it ends up looking more like this. Which gives us a bit of a usability problem since the sever names don’t *look* like we can interact with them.
- So I’m going to change the CSS to add that entire grey button using generated content, moving these presentation decisions into the CSS where they belong. I’ve also added speak:none to the declaration so that the weird unicode character won’t be read out. Generated content is mostly not read out …
And, of course, we’ll update the corresponding declaration for hover and focus.
Let’s check in with the browser to help us visualize what we’ve done.
We just made the hit area of these buttons wayyyy bigger. The entire bar is clickable, press-able, and touchable now, and assistive technology will associate these buttons with the names of the servers, rather reading them out as “details, details, details”
We’re also taking advantage of Fitt’s Law…
Fitt’s law basically says, the bigger something it is, the *faster* it is for us to interact with. So while voice recognition and trackball users might see the most returns from this, all our users are going to find it easier to interact with those buttons.
We still haven’t solved Steve’s problem though, have we? Let’s fix that by adding an icon with a text fallback.
I’m going to do that using a very similar syntax to what is outlined in the Filament Group’s excellent blog post Bullet Proof Accessible Icon Fonts. Really great article.
I’m going to add the icon using CSS generated content but I’m not just going to rely on speak:none. I’m going to go a step further and add a span element to the page as my hook for the icon and put our first ARIA role to that. Aria-hidden has much wider support than speak:none and we can depend on it.
So there’s our generated content icons.
And we’re also going to provide a text fallback.
Resist the urge to make the fallback “check mark” or “x” just because that’s what the icon is. Instead, think about what we’re trying to communicate here. The important information is whether or not the server is up or down, so that’s what we’re going to use for our fallback text.
This is effectively what we have at the moment but I’m going to hide that fallback text…
Using a class I’m calling offscreen.
Hiding content from our visual users while making it available to screen readers and other users who consume our content without visual formatting is not as easy as declaring display: none. In fact, screen readers will respect how we as developers use display:none by not reading it out to their users. They also won’t read out the contents of elements with a 0 height or width. So we’re borrowing a technique developed by Jonathan Snook when he worked for Yahoo. He’s written an excellent blog post on it, which I encourage you to read. This class might look familiar to some of you, it also ships with HTML5 Boilerplate as visually_hidden and bootstrap as assistive-text.
So with our fallback text safely out of the way now we have icons for our colour blind users. Lots of other people benefit from these enhancements too, English as second language users, users with cognitive impairments, or users with learning disabilities will all understand our meaning faster when we combine words with icons and other visual cues like the colours. And there’s one more group of users we just helped out.
Hello high contrast theme users, we haven’t forgotten you.
So, what just happened there?
We chose the right HTML elements for the job. Just by going from span to button we gained the ability to focus on the element with the keyboard and event handling for click, tap, and key press, all provided by functionality already built into the browser.
By using descriptive text for headings and buttons we made it easier for screen readers and voice recognition software users to navigate and improved the search engine optimization of the page.
By creating larger hit areas for people who use voice recognition or trackballs we also made it easier for touch screen and in fact, all users to get to those buttons.
We added icons for colour blind and high contrast theme users, icons that will help everyone understand our content faster. We also added presentational visual cues but we kept those in the CSS.
And we provided text fallbacks for the users that can’t see those visual cues.
What we did doesn’t look all that different does it?
But it *feels* different. It feels like good, well crafted, code.
And if this is all you do, this is a better experience for a lot of people.
Before I go, though, I want to show you a more complex example of ARIA attributes at work. As I said before ARIA is extra attributes you can add to your HTML to make make it clear-er to screen readers the purpose of different elements on the page and how they interact with each other.
The two elements that are interacting with each other here are our button an our list.
So we’ll start be linking them with aria-controls and an id. The value of the aria-controls needs to match the id of the element that it control.
Next we’ll add an indication of the functionality here. ARIA-expanded signals that the controlling button element expands and collapses the list element it’s linked to, and that currently the list is collapsed. We’ll also add ARIA-hidden to the the list, to collapse it in the eyes of the screen reader.
turning this into
this. If you want to chain this together with jQuery’s toggle functions you can. But I’m going to make the far-out suggestion here that you just rely on these attributes to do all your work for you.
We can use aria-expanded to style our buttons as well. \25BE doesn’t sound much like the down arrow but…
It looks like one. That’s the kind of attention to detail that will get you noticed by a Steve.
I have both the before and after versions of this code up on my blog and if you’re thinking you’d like to play around with some assistive technology yourself, these two examples will give you a feel for how much of a difference you can make.
- we don’t ask 2nd narure don’t pitch
This might sound like a lot to take in but I want to remind you that there was a first time, a very first time, that you learned what a function declaration was, looked up the difference between a radio button and a checkbox, and Googled the different between a class and an ID.
These are all second nature to us now. Web accessibility can become second nature too. Once you’ve learned the basics it integrates into your workflow without taking any extra time and makes your websites better.
When we pitch to our clients or our bosses we don’t sell them on semantic HTML and we don’t start putting paragraphs and headings in span tags if someone tells us it’s not important. Like semantics, accessibility is part of making a good website, one you can be proud of because…
a11y = good descriptive text, larger hit areas, icons raise hand if
…when we make our sites more accessible we make them easier for *everyone* to use.
Raise your hand if you have ever: clicked on a form label instead of the form element, if you’ve ever submitted a form by hitting enter, read a transcript instead of watching a video, tried to use a site after your Bluetooth mouse died, injured your hand or arm, tried to use a touch screen with your nose, or, finally, raise your hand if you’ve ever used a search engine. If you have your hand up, you, personally, benefited from web accessibility whether you knew it or not.
So even if you don’t have a Mike or a Steve in your life to inspire you - you can use accessibility techniques to make your sites better for all your users.
And the next time you start a new project: Think about what your users can and cannot see. Thank about what they can and cannot interact with. Don’t screw up HTML’s native accessibility. Do what you can to make your site better. Make a difference to someone and make a difference to everyone.
My name is Stephanie Hobson and I like to make websites everyone can use.
(pause) Read out slide Slides are on site
Web Accessibility: Making Websites Better for Everyone
BETTER FOR EVERYONE
Page has fifty-eight headings and two hundred
seventy-one links BBC dash Homepage Link
Graphic BBC Heading level two Heading level
two BBC navigation List of nine items bullet
Link News bullet Link Sport bullet Link Weather
bullet Link Capital bullet Link Future bullet Link
Shop bullet Link TV bullet Link Radio bullet Link
More… List end
When the HTML markup reinforces the
meaning (aka semantics) of the
information on the page.
(Web Content Accessibility Guidelines)
Americans with Disabilities Act
Nat’l Federation of the Deaf vs. Netflix Inc
Department of Justice
Advance Notice Of Proposed Rulemaking
Canadian Human Rights Act
Ontarians with Disabilities Act
Schedules I, I.I and II of the Financial Administration Act
Don’t screw up your HTML
Make small improvements