Web accessibility, in terms and tools you already know

I'm Matthew and I am going to be talking to you about web accessibility in terms and tools

that you already know. Just a little bit about me to start with, I'm involved with the W3C,

I have two roles within W3C. I'm a member of the technical architecture group and I'm

a co-chair of the accessible platform architectures working group and both of those groups look at all

sorts of standards proposals that are coming out accessibility or otherwise and make suggestions

to the people that propose them to help them improve them. The technical architecture group

looks at overall architectural fit for the web platform and does some very deep reviews in that

regard and the other group whose name is very long does specifically accessibility reviews amongst

other things but that's just a flavour. Also by day I work as head of web standards at Samsung

Research and Development Institute UK and leading a small but awesome team working on all sorts of

standards across the platform and in support of Samsung internet which is our browser. What we're

going to look at today is we're going to do a speed run of accessibility, we're going to then

talk about accessibility in terms that you already know and then we're going to look at some practical

things that you can do as developers to experiment with accessibility. But why are we here? So

Frank Herbert said fear is the mind killer, a very insightful phrase and when we talk about web

accessibility sometimes our pulse begins to race because we've just been told to do this thing

and we want to do it but we don't necessarily know how to do it and then when you start thinking

about web accessibility you move on to assistive technologies and it gets a bit scarier because

then you think of course of screen readers. This is a picture of a terminator not a screen reader

but that is how it makes you feel when you boot up a screen reader for the first time and it starts

talking at you in its scary robot voice. But as lots of people over the years have observed

knowledge is power and as technical people you already have the knowledge that you need to

understand how accessibility actually works under the hood so you can tame that robot somewhat.

Okay but before we go on to that just a couple of really important things.

A range of accessibility barriers exist it's really important to bear that in mind and also

a range of assistive technologies exist to address them. You will see me using one of them during

this talk it's called the manual zoom when I get to the live coding you'll see me do the manual zoom.

Excuse me. Okay and also pretend that you've just seen Geri's talk which is going to be awesome

about shifting left you need to do that. She will explain what it means but basically accessibility

needs to start from the design stage. This is a technical talk or it's aimed at technical people

who want to understand how accessibility works in the browser so that you can debug it a bit

more and understand it as developers but by the time stuff gets to you as a developer it should

have already gone through a very robust process of consideration of the user's needs and all sorts of

good stuff that Geri is going to talk about. So accessibility speed run okay I have got a

form on the screen and this is I'm just going to tab through this form with the screen reader

and it's not going to say anything.

There we go. So we've got one text box which is blank another text box which is blank

and it's the sound is a bit choppy unfortunately but I'll tell you it's saying that there's a

button there so what do you think this form is can anybody guess what this form is it's got two text

boxes and a button login it is a login form so I am going to tab through it username okay now we've

got the labels associated we can hear what it's about I'll just try that again it's not saying

what I want it to say which is because it's missing off the beginning of a button I'm going

to try this one more time there we go sign in button but it says login on the screen why

we'll get back to that okay so how do we make things accessible okay what you do is you don't

make them inaccessible it sounds glib but it's actually quite true the web is full of things

that are designed to be accessible so buttons you put some text in a button it becomes its name

you can associate form controls and their labels you know you already know how to do this

headings headings work you can skip around between heading levels you can use landmark regions if you

don't know what they are we'll talk about them briefly later but use things like main and nav

and people can skip to parts of a page really easily but why do they work we know we should

do them but why do they work and what if you're making a custom widget that does something that

isn't done by a standard element how do you make that work one of the big things that people ask for

is to put images and other stuff inside select choices and you can't do that with a standard

element so people make custom ones and then they have to do the accessibility

however actually with this particular use case because everybody asked for it so much

the Open UI project is working on an element that will hopefully become a standard that does this

stuff for you so this might get a lot easier in future but coming back to okay how do we make

things not inaccessible we use the web content accessibility guidelines or WCAG which i'm sure

you've all heard of but just very briefly you need to follow four principles and the guidelines

inside WCAG are numbered along with these principles so perceivable it needs to be the

user needs to be able to take in your content they also need to be able to interact with it or

operate it it needs to make sense to them so it needs to be understandable to them and it needs

to work across all of their devices and assistive technologies and if you want a good guide on how

to do that there's a quick reference for WCAG which is really really cool and it tells you all

the detailed things to do but again why do these actually work what's the what are the underlying

mechanisms well we're getting to it so when you think about somebody browsing the web you've got

the content which you provide i mean you've got the browser or the user agent as we often call it

in standards circles i mean you've got the user and the user interacts with your content through

the user agent okay but if they are using an assistive technology you've got the content

then you've got the user agent and then you've got the assistive technology whatever it may be

which talks to the user agent and the user interacts with some combination of the assistive

technology and the user agent so sometimes the assistive technology trans does some translation

for the for the user in order to do this they need to talk to each other the AT and the user agent

and that's what we're going to be focusing on for the rest of the talk so you actually already know

how this works i am certain that this stuff that we talk about will be familiar to you and hopefully

it will help you understand a bit better how this stuff functions so i'm going to talk about trees

objects and properties and orders of precedence these are all things that as techies you've come

across so trees okay the accessibility tree we're browsing a web page this is a page which has a

picture of a rainbow cake and a button called light candle and i will see if i can get the

screen reader to actually talk about it oh no i can't because i forgot how to use my own slide

system i need to press one more button first okay and now if i press g it takes me to the next

graphic on the page and it says figure cake because it's in a figure element and um how does

it know it's a cake we'll get to that and i've tabbed onto the light candle button um but i'm

not going to uh have a naked flame in the room so don't worry i'm not going to press it um but how

does this actually work well if we look in the dev tools we can see this very familiar view which is

the the browser creates the DOM tree in memory and this is like a living version of your HTML and all

sorts of stuff can happen to it we can expand it like this we can see the image in there

we can also see if we're using a particularly evil web framework like the aperture science

web framework we get div soup so it's full of things like class names like aperture science

1500 megawatt super colliding super button container wrapper and stuff like that and it's

those all the way down lots of div soup um this is what you're familiar with looking at but

if you're an assistive technology you need some of this information but not all of it

so let's just look at the accessibility tree which is very familiar it's stripped out a lot of stuff

it's taken away all the div soup because the divs don't add anything meaningful to the page but it's

kept things like the figure it's kept things like the caption in there um with some divs which have

been ignored i mean you've still got the image with the with this alt attribute and all that

sort of good stuff and the button so this accessibility tree is like a subset of the DOM

that you're familiar with it just contains the stuff that's important for accessibility that's

as simple as it is um so let's talk about objects and properties okay so when you

make your web pages your web content these things these links and images and stuff they become living

objects in memory and they have properties like the link has an href the image has a source

attribute and an alt attribute and also the image has a text content property which is the text

inside the the node from an accessibility perspective what's important then what do we need

to know if we're an assistive technology to help our user so for every element or object in the

system we need to know its name what's it called if there's a description there might be some

ancillary info like instructions for filling in a form field quite optional but could be useful

its role what does it do uh its state what's been done to it and its value input from the user so

let's go for a couple of examples um this is a button it said it knew it was a button so it said

button its name is released for hounds it doesn't have a a value and it doesn't really have a state

let's just ignore disabled for now because that's something that you're probably all familiar with

i'm just concentrating on new bits for you but we can trigger the button

and then something happens um

this is text in a box so it says edit text in a box because it's a text box and there's text in it

but there's no name which so the role is text box the value is text in a box or i might change it to

slartibartfast um and it doesn't have a name which is really naughty so if we look at the

properties here it doesn't have a name so we we don't know really what what to do with it

so let's fix that and we can fix it by just adding in a label what's your name

and i'm going to be lazy but also cool and wrap the label around the thingy and now if i inspect

it after wrapping it in a label element it says what's your name from the label it gets gets that

from the label so that's that's pretty good um very easy so the next one this is a check box which

also doesn't have a name so that's bad but it does have a state it doesn't have a value so the state

is checked or not checked and the last one samsung internet browser this is the image and the samsung

internet browser is the alt text for the image so um this has alternative content that can be

provided so this is why all that best practice stuff that you're told to do works because

standard html elements expose all this stuff for you um sometimes you need to provide attribute

values or alternative content but it all works the plumbing is all there it all gets exposed

through that tree and the at picks it up if you make a custom element you um you have to provide

all of that information because it's not there by default and the behavior including keyboard

handling and the styling so this is why uh generally you should avoid doing that if you do

need to do it you can use the role attribute and the various aria dash attributes that you've

probably seen aria stands for accessible rich internet applications which is a um another

standard from W3C which helps you provide this information and like WCAG there's a really good

guide if you need to make custom widgets on how to do that but again the the goal is to try and

avoid needing to do that but if you do need to do it there's a good reference there um so let's also

talk about order of precedence again this is something that you're familiar with so this

example is a table with a shopping basket and some remove buttons at the ends of each of the rows

and the remove buttons but all they've got in them is a unicode wastebasket character so let's see

how that gets announced so that was quite handy because i switched between rows of the table it

was clever enough to use the row header to give me some context as to what the the labels were

which is cool but one way that people browse around is by looking at the names of the buttons

on the page and they're both just wastebaskets so that's not really very useful we can make this

more useful so let's try and do that first of all we can look at the button and inspect it and see

that the name comes from its contents which is the unicode wastebasket and it announces that as

wastebasket so you can kind of maybe guess what this button does but it's not necessarily entirely

clear if you're not browsing visually and you're not aware of the visual relationships between

stuff so what we can do is we can add a attribute which gives it a label or a name i should say

so we can say remove and now what's happened the order of precedence has kicked in it could have

looked at the contents of the element for its name but i've said no actually i want to override that

and i want to give it the name remove so that's pretty cool but there's a problem can you spot

what the problem would be if i did this for both of the buttons they'd both just be removed so i

haven't actually really improved stuff that much so what we can do is we can take advantage of the

fact that the row header has an ID as well and we can override this again and include both the row

header and the name remove in the label sorry the name for the button so i will just do that now as

well and what i'll do is i'll say aria-labelledby and i'll give the ID of the button itself which is

going to be remove so that's remove one did i type that properly yes i think i did manual zoom as i

said um and remove and the ID is i term one and that should say yes remove pineapple and it comes

from again we've gone up another level in this order of precedence this is overridden what we

had before but it's also referencing itself which is kind of cool um so now the button labeled is

remove pineapple and if we look in the list of uh controls i've only done the one but you can

oh no you can't see that because that's the dev tools list because the dev tools is also our web

page which is also cool um so button remove pineapple so it's in the list there is that's

what the screen reader will say and so that's just using this order of precedence to your advantage

also again very simple oh and coming back to this sign-in why did it say sign-in because

somebody put an aria label attribute on it that said well it was me actually but

um but the point is the point is you might think well why did i do this is a silly example it's

actually not a silly example um this happens a lot because frameworks tend to try and be helpful

and sometimes they are a bit sort of uh enthusiastic about setting these attributes and

as they say out of sight out of mind you can't see this as a visually browsing person but

it's there and it's very easy for these to go out of sync so it's really important to bear that in

mind um right okay so last little section um practical tools well we've just looked at the dev

tools quite a bit actually um as you noticed um the mouse on its own is good i mean this is mouse

in conjunction with dev tools but i've just got a picture on the screen of the sort of pop-up that

you can get when you are inspecting something in the page and it will tell you things like its role

its name whether it's keyboard focusable its contrast ratio it's really really helpful also

i've got on the screen now two example i well identical looking checkbox with labels they're

both a checkbox followed by a label that says agree to terms and conditions but there is a

difference if i try and click on the first one i just end up selecting the text if i click on the

second one i actually um activate the checkbox that's because the second one is done with a

label element now you might know this already but it's super cool because it gives you a bigger

touch area and you can tell that these are associated now the top two could actually be

programmatically associated because you could have used aria-label or aria-labeled by but using the

label element gives you this extra bonus which is the touch area and it's also possible to make the

second one not work by using aria-label too so you still have to check you have to get people to test

your stuff but as a spot check this should give you a bit of confidence that some thought's gone

into the the way it's been coded but of course the real power tool is obviously the keyboard

everybody knows using the keyboard is cool if i i have a form here that says email address

sign in with access code and a terms and conditions link and i can hover over this sign in with access

code button but when i use the tab key it skips over it completely and that's because this wasn't

this isn't really a proper button it's just a span so i'm gonna i don't need to tell you don't do that

but just just to just to reinforce how useful it is to just try and use something with the keyboard

okay last little bit browser limitations so the dev tools are amazing you've got all this power

to hand now and i hope that you can see how to do to how things are working and maybe how to debug

stuff a little bit but there's some things that browsers don't do or don't expose yet

i talked about these elements earlier or some of them aside footer header main nav and section

under various circumstances but most of the time let's say when you use these you get something

magic called a landmark region and that allows somebody who's using an assistive technology to

skip to that part of the page so you can skip over the navigation links you can go back to the

navigation links you can go to the footer you can go to the main content you can get an overview of

what's on the page in terms of broad areas of it and it's super super awesome but the browsers

don't really expose it i mean you can inspect them and get the appropriate roles and you can see

the role that's being exposed through the dev tools but it won't show you a tree that you can

use to like check things it won't let you visually highlight them and it won't expose them to people

who don't use assistive technologies lots of people who use a keyboard might want to access

these but they can't except you can use browser extensions this is one i maintain but it's not

the only one that that is works in this area it allows you to navigate landmarks with the keyboard

and it also shows you a little tree in the dev tools with some information about how you might

want to improve the accessibility but this is the landmarks browser extension but hopefully browsers

will do this at some point the dev tools are always improving so you never know so the bigger

picture again come and listen to Geri's talk um i know there's one other talk as well and i'm sure

it's going to be awesome but it just these fit together really well in particular as far as i'm

aware um other stuff prefer using standard html elements have real people test your work please

do that if you possibly can and don't be afraid to experiment so hopefully the scary robot is now

looking a bit more friendly this is a picture of roz from the wild robot who's cradling a

delicate little bird in her hand so um thank you very much for listening um i will publish these

slides at some point soon uh until then there's some acknowledgments for the images i used thank

you very much