Speaker Notes : This is for everyone
Front-Trends, 2015
These are my raw notes that I made for the talk Im about to give at Front-Trends conference in Warsaw, Poland.
This isn’t a blog post so little care has been taken with spelling and grammar, its more of a brain-dump and should be treated as such.
The slides are here :
When sites are correctly designed, developed and edited, all users have equal access to information and functionality.
I think the most important part of this is the ALL Users should have equal access.
When Sir Tim Berners Lee tweeted from the opening ceremony at the London 2012 olympics “This is for Everyone” he was talking of course about the Internet. XX years before his tweet he, as we are all aware of, ‘Invented’ the internet. It was in the early days a way to share knowledge and at its core, no matter how many GIFs we upload, still is that. Not only that, but sometimes the things we build, the social networks, the forums — they connect us and become part of our lifestyle.
The social networks, the newspaper sites, online education, tutorials and workshops. The world wide web that Sir Tim Berners Lee gave us, is for everybody and we can do our part as developers, designers and UX’rs to ensure that everybody has as easy access as possible to that wealth of knowledge.
The current state of accessibility kind of feels like a little bit of a job half done. I think there’s some of us who sort of half do it, maybe there’s a gap in education about making the web more accessible and then sometimes is just that people flat out think its a difficult thing to do.
I’ve found that when a lot of people think about accessibility on the web, they immediately think about people with visual impairments. The key things that I’ve personally found people jumping to whoever accessibility is mentioned is either tabbing through the page or the use of a screenreader. Whilst both of these do have something to do with accessibility, they’re not the only conditions that might affect someones use or interactivity with the things we build.
VISUAL
Users with low vision, obstructed vision or colour blindness. Users with low vision might use a screen magnifier so you might want to make sure that click areas are large enough with enough spacing apart. User with colour blindness to certain colours might have trouble separating something that is red for example, so if all your links are only discussable by being red in colour you might want to consider having an underline too.
Picard Quick Tip.
Try not to use
maximum-scale=1.0in your viewport meta tag because this disables the users ability to pinch and zoom. I know the designer thinks that they have the perfect type setting, font-size and line height down and in that case want the user to not be able to zoom — but its important that they realise they’re wrong and someone wants to zoom and they should be able to.
AUDITORY
All too often I have found myself embedding videos on the web and anytime I have asked for a suitable subtitle file, its always been a pain to get some sort of transcript. Fight for it if you’re in this position, its not a hard thing to implement as a developer as the html5 track element has pretty good support now and most video players have fallbacks. Its also worth saying that if you have a podcast, it’s bee great to see more transcripts out there.
MOTOR
Motor is a pretty big one because it can cover a whole range of assistive technologies, from someone who suffers with RSI and primarily uses a keyboard to navigate, to someone who might use an assistive joystick or eye tracking to move the mouse around. We’ll dive in a bit deeper to keyboard navigation in a bit, but for the other assistive technologies it can be as simple ensuring that hit targets on buttons and links are well defined and have some space between them if they are bunched up together.
So today, I want to go through 10 things that we can do as developers that are super easy, can become part of you workflow and together we can begin to make the things we build a little bit more accessible to as many people as possible. So, in no particular order of importance.
Im not here to make you feel bad. I am by no means an authority on accessibility, just a programmer who finds the subject interesting and wants to share some of the things that I’ve learnt.
10 — Accessibility First.
You’ve heard of Mobile-First right? Big thing, maybe sometime used as a buzzword by sales people and recruiters, but really it was pretty good advice. But if you have a Mobile First approach to you’re code you’re thinking about small screens, low powered devices and slow connections first and by building your pages in a way that makes them fast, snappy and responsive in that environment you get a much better user experience for everyone, no matter the screen size or connection speed. Also, if you’re building a responsive website, its a lot easier to go mobile-first that trying to bake in the mobile layouts after, using progressive enhancement (another dangerous word).
Its the same with accessibility. Its something thats a lot easier to do from the beginning rather than try to bake in the last 2 days or when your PM comes along with a WCAG report that has a bunch of accessibility failures that you have to fix y the end of the day. Thinking about accessibility upfront can also influence UX and make the site or application simply a little bit more usable.
9 — Keyboard Navigation.
I know what you’re thinking, Who doesn’t use a mouse, right?
People on the Enterprise don’t use a mouse.
Vim Users don’t use a mouse.
From personal experience I just find it a lot easier to navigate my most-visited sites using just a keyboard. Reddit, Gmail and other sites I use on a daily basis have good keyboard-only support and whilst I can use a mouse when necessary, there are a lot of people who cannot. Adding basic Keyboard support isn’t difficult either, you just have to remember that wherever you add a click, you might need to consider adding a keyboard input event such as hitting the enter button or using the arrow keys to navigate a carousel. The BBC’s main site has a carousel on it’s homepage and it’s really nice to use with just a keyboard.
Tab ordering is also important when it comes to Keyboard navigation, some native HTML elements are inserted into the tab order of the page such as Headings, Form fields and links, but there are also these ‘semantically neutral’ elements that don’t get inserted into the tabbing order that we might want to be able to navigate to AND through with the keyboard. Thats where we get onto
tabindexIf the tabindex isn’t used on an element then it will follow the convention of the element. If its a control element such as a form field, button or link it will be in the tabbing order of the page, but if its a span or a div, it will not.
tabindex=”-1"will allow an element be programatically focusable. This means that you can respond to keypresses and send focus to an element that has this tabindex using
.focus()in JS. This is good for when you are creating those custom selects and wants someone to be able to use arrow buttons to be able to make a selection. This is also good for when you open a modal on a screen.
tabindex=”0"will put the element into the natural order of the document. So if you are using divs or spans as buttons, or even using HTML Web Components, you will likely need to add tabindex=0 in order for a user to be able to access that element.
tabindex=”[1…99]”any positive integer will put the tabbing order, in the order that you declare. If you think you need to control the tabbing order, beware, its not easy to maintain the natural tabbing order.
:focus{
outline:none;
}Don’t disable the `:outline`. Designers hate it, that blue outline you get on focus, but its really important for people using keyboard navigation are able to tell where they are on the screen. It does’t have to be that blue outline, but elements that receive focus should always have some sort of visual key. If its a button or a link, give `:focus` the same treatment as hover and if its a form field, heading or navigation element, give it some sort of outline or visual state that makes it obvious when we are on the page.
8. Skip Navigation Links
Sort of comes into the keyboard navigation area of things, but I believe its important enough to be in and of itself. Its something thats possible for everyone to go away today and implement into any project that you might be working on.
<body>
<a href=”#main”>Skip Navigation</a>
<nav>
<ul>
<li><a href=”#”>Home</a></li>
<li><a href=”#”>About</a></li>
<li><a href=”#”>Blog</a></li>
<li><a href=”#”>Contact</a></li>
</ul>
</nav>
<div role=’main’ id=’main’>
<! — Main body of content →
</div>
</body>Someone who uses a keyboard for navigation, visual or not, can often find it fatiguing to continue tapping through repeating content across pages, this commonly being navigation — so it’s a common pattern to make a link that sends focus to the main content of the page the first element in the page, so that the first tab allows a user to just skip to the content.
7. Alt tags
ALT tags is something you’re told about right at the beginning of your career as a web developer and then it seems that you just one day, stop adding them. Has anyone ever had one of those WCAG2.0 Reports done on something they built? Everytime they come back there is always something about Alt tags.
The alt text is meant to help the user not miss any content, Its not only something thats used by assistive technologies, but maybe also used when people switch off images in their mobile browser to save on data.
If your image is part of the content, then it should have some relative text in the alt tag.
If you’re having to use an image for purely decorative reasons and its not relative to the content, then still use an alt tag, but just have it as an empty string, that way assistive technology knows to just skip over it and ignore it. You might also use this technique if you have an image for a graph and descriptive text underneath.
6. Forms
Forms by default are pretty good for accessibility. The few things you can do as a developer is make sure that the forms tabbing order makes senses. Labels are a massively important part of forms, on a UX side of things, labels tell the user about the expectation of that field. For someone using assistive technology might also need something like a screen reader or Braile output, they need a label associated with the field and no, placeholder text does not suffice. Of course, maybe you don’t need labels to be show to people who can see a form, thats where we can use a little CSS magic.
.sr-only {
position: absolute;
width: 1px;
height: 1px;
padding: 0;
margin: -1px;
overflow: hidden;
clip: rect(0,0,0,0);
border: 0;
}Many popular UI frameworks have a helper class a little bit like this. This allows you to keep elements that assistive technology use in the natural flow of the document, but hide it for visual users. So you can use this on labels if you don’t need them for visual users.
And before anyone asks, no, I’ve not found a way and I don’t think that there is a reliable way of detecting someone using a screenreader in JS and Im not too sure about how I feel about the idea of that being a good thing. I don’t think you should be thinking about a layout for assistive technology.
5. ARIA
ARIA allows us to extend HTML. We can add additional attributes to elements to allow us to communicate to assistive technology.
We can assign roles to let assistive technology know its purpose.
We can use aria-states and properties to communicate the state of an element. On Friday Leonie Watson is doing a talk on ARIA, so make sure you catch that to dive into ARIA and how to use it.
4. Landmarks
Landmarks are specific roles assigned to elements to allow AT to navigate directly between them. Someone using AT can navigate between these landmarks. Again, be sure to attend Leonie talk on Friday to no doubt find out a bit more about Landmarks.
3. Media
I mentioned before that if we are using media on a page, we should also provide subtitles for video and transcripts for any audio content. Its also important to not have video or audio auto-play when the page loads. We all know how annoying auto-playing video is, imagine if sound were your only means of navigating the web and you suddenly have this. Video controls are more than apt and I am yet to come across a requirement of auto-playing video that can’t just be put behind user controls.
2. Testing
Doing all of these things are fine, but testing is an important part of that. Not just testing our code, but I think its important that we test our tools too. Spend some time with a screen-reader, or learn about keyboard only navigation on pages. The next time you finish up a feature or a page, put its through its paces. If you’re code reviewing a peers work, educate them on how they can ensure their work is accessible by AT.
1. Lets talk about it
The last thing that I really think will help is that we start talking more accessibility. Talk about it with our peers, talk about it more at conferences and share the things we’ve learnt. Im not talking about calling each other out on twitter, but working together to help one another fill in the gaps we see in our work.
There are some things that you can’t fix as a developer. Design and UX might be something thats totally out of your hands, but that doesn’t mean that you can help educate. Colour and contrast are interesting things because its something that certainly gets looked over in a lot of cases, and then there are a lot of interesting things around typography such as the types of fonts used that help people with cognitive problems.
Picard Quick Tip
jQuery UI is a great learning resource, they have an excellent standard for ensuring that the widgets they make are as accessible as possible. If you ever wonder how to make tabs or carousels more accessible, have a look at how those components are implemented in jQuery UI, how they’re structured and how they use ARIA and how they use JavaScript to handle focus and keyboard input.
Tooling
So what tools are out there that can help us?
Accessibility Developer Toolbar
Chrome ADT is a great place to start. It allows you to run an audit on a page much like you would a performance audit. It feeds back with information on form inputs with missing labels, or maybe an element that is focusable, but obscured by another element. It also has a tab in the inspect element view where you can select your DOM element and see the accessibility properties of that element. There are also some equivalent tools for other browsers.
Chrome://accessibility
On the subject of chrome, if you want to see the accessibility tree — this is the rendered tree that AT uses as apposed to the DOM tree that you might be used to. You can use this if you need to investigate what affects certain ARIA states or properties might have.
Tenon.io
You can use Tenon to run an audi via it’s API, it will then respond back using JSON. This can be useful for QAs running automated testing and be run in your CI workflow or something similar.
Screen Readers.
So beyond these other tools that can test our code, you might want to actually test something with a screenreader, thankfully they’re available on all platforms, including the ones we have in our pockets and generally are free to use and the paid ones usually come with a free trial. It can take some getting used to when using a screenreader, but I think that if you are serious about understanding how a lot of people will access the things that you build, its time thats worth investing.
Resources
Youtube playlist
So lets go from boring beardless Riker, to awesome bearded Riker. Lets make the web more accessible.
My name is Shaun, Im a developer based in London in the UK. I’ll be around for the rest of the conference if you want to talk about anything I’ve spoken about or if there are any questions, or you can find me online usually under the moniker of @shaundunne.
Thanks.
