[MUSIC]

[APPLAUSE] >> Thank you very much and good morning.

And thank you everybody for coming to this talk.

I really don't need to introduce myself after

that comprehensive introduction from Ian.

One thing I will say though is that sometimes asking questions at conferences

like this can be a little bit scary, so my Twitter details are up on pretty

much every slide so if you don't feel like asking a question through the talk or

at the end, please come up and say hello afterwards or ping me a Tweet and

it'll be good to catch up and carry on the conversation.

So a conversation about what?

Well, making interfaces accessible so that people really want to use them.

Accessibility to my way of thinking has a bit of a brand problem.

It makes people think of legislation and conformance and guidelines and

being sued and all kinds of nasty bits and pieces.

But actually, for me, it's something much more fundamental than that.

It's just about designing like we give a damn.

Like we give a damn about the things we put our hearts and

souls into developing and creating, but

mostly like we give a damn about the people that are gonna be using them.

What I'd like to talk about today is my take on designing like we give a damn and

accessibility to offer some ideas about how we can make it happen in

a really practical sense and to look at the experiences of someone like me

who uses a screen reader to access computers and the Internet.

And to do that, I am gonna share four principals that I've used before that

explain my theory of designing like we give a damn.

>> Slide two: Design like Banksy [INAUDIBLE].

[INAUDIBLE] >> Oops.

What I should explain is that's my screen reader you're listening to there at about

the speed I tend to listen to it.

So don't try and follow along.

It'll probably drive you a bit nuts.

But trust me, it makes sense to me.

Or at least as much as anything ever does in this life.

So the first principle of designing like you give a damn is to design like Banksy,

which is to say read the rule book, understand it but don't ever be afraid

to challenge the accepted wisdom, rip it up and start again.

There's a lot of information out there about accessibility.

That maybe once was true, but certainly is no longer true, or is downright incorrect.

And I just wanna share some of those myths with you so

we can perhaps start to put them to rest for once and for all.

>> Slide three: Accessibility.

Accessibility.

>> Accessibility stifles innovation.

This is something I hear a lot, all of the time.

When you think about accessibility, people get a bit like, oh my goodness,

now we're going to have to put everything in black and white, and

it's all going to have to be just non-interactive and

there's going to be no shiny, that's really not what it's about at all.

If you get an idea for a product or a web application or

an app, whatever it is you want to build, don't let the thought of having to make it

accessible put you off innovating in the technology in itself.

All you need to do is just make accessibility one of the many

things that you think about when you're innovating.

You can innovate within accessibility as much as you can within any

other area of technology.

So don't let it stifle your imagination when it comes to building stuff.

Just think about the people that are gonna be using that product and

make the accessibility part of the innovation.

>> Accessibility kills creativity.

>> Accessibility kills creativity is something we hear quite often.

On screen, there's just a cast of my business card website.

You'll probably gather from the slides that I've got a bit of a thing for

the film noir kind of thing going on.

It's the same on my blog.

And a friend designed my business card website with a bit of CS animation just to

give it a bit of interest.

This is perfectly accessible.

It's all good semantic HTML.

You can turn off the animation if it's too distracting for you.

But, hopefully, it gives you an idea that accessibility can be something creative

and, like innovation, think about accessibility when you do the creation.

Don't let it slow you down.

>> Accessibility is difficult [INAUDIBLE].

>> This is something we hear a lot.

Accessibility isn't difficult.

What it is, actually, is unfamiliar for a lot of people.

What you guys do everyday is the difficult part.

You've learned JavaScript, HTML, CSS,

you've got those things most of the time to work in most browsers, and frankly,

if you can do that, everything else is pretty much a cinch.

The unfamiliarity is what slows people down with accessibility.

It's easy to know what it feels like when someone uses a tablet or

a desk top or a Netbook or a Macbook or whatever it may be.

But the chances are, you might not know what' it's like to use a screen reader.

That translates content into synthetic speech.

Or, to use speech recognition where you control your computer entirely

through voice commands.

But all of those things are pretty achievable.

We've got a MAC, hit command F5 and you'll get a screen reader.

Play around with it a little bit.

Know that it's command F5 will turn it off again so

otherwise you'll get stuck forever.

Most technologies on Windows you can download a free screen reader called NVDA.

From nvaccess.org.

Download it, grab it, play around with it.

You can get your hands on pretty much any kind of assistive technology, so

just take those first steps, and

experiment to remove that kind of level of unfamiliarity.

>> Slide six: Accessibility is irrelevant.

How families in an automated car driving along the highway next to a futuristic.

>> Accessibility is irrelevant.

A lot of people will say, well, you know, it's just for people with disabilities and

there's really not many of them out there in the world so, yeah, you know what.

The simple fact is that if you think about accessibility now you're gonna be making

things a hell of a lot better for yourself in 25 or 30 years time.

It's a sad but true fact is, as humans we tend to get a bit slower,

a bit less capable as we get older.

But the interesting thing about us now is that if you think about your older self,

your future self.

Are you really gonna have the patience and the tolerance to put up with a web

that won't let you go out and do the things that you do?

My hunch is, pretty much not.

If you've been used to using the internet to do whatever it is you want through your

younger life and then suddenly because your eyesight starts to deteriorate or

your hearing goes a little bit as you get older and

suddenly you discover you can't use something.

That's not gonna be an acceptable state of affairs for any of us.

So it's very much thinking about our future as

well as people in the current time when it comes to accessibility.

>> Slide seven: Design like Da Vinci.

>> So the next principle is to design like Da Vinci.

And never stop being curious about how we can make things better and

that's really important with all kinds of technology cuz very much that's

what we want to do with technology a lot of the time.

>> Slide eight: Perfect is the enemy of good.

Each carrot is a different shape, none of them conforming to the perfect shape.

Backslash. >> So enemy.

>> I'm having real trouble with this.

Perfection is the enemy of good.

You've got a bunch of lumpy carrots on the screen, I think.

It's dreadful trying to find a picture for this.

When you think about accessibility, there's a temptation to think that it's

gotta be perfect, and this comes back to this idea of complying with the law.

Needing to conform with some set of guidelines.

That's actually a really dangerous way to think about anything but

especially accessibility.

Because if you start to think about it having to be perfect,

you just quail at the whole idea.

It seems unachievable, insurmountable.

And then, quite often, you don't wanna take the first steps.

The truth is, is that with accessibility,

even if you do just a couple of little things,

you're going to be making a difference to somebody somewhere out there.

So don't worry about the big picture, just keep doing little things every day to

make a difference, and there's quite a few things we can do to make that difference.

>> Slide ten: Interaction.

>> Interaction.

If your an interaction designer think about talking to people.

And I think I just skipped a slide actually.

Which is to say we don't want to just keep throwing things over the wall.

Shout out if you've ever been working on a project where the interaction designers

and the prototypers have put together a fantastic set of interaction designs.

Handed it over to the design guys who've made it look beautiful and

absolutely fantastic.

Handed it over to the developers who've taken one look at it and

gone, we can't build that on the platform we're working on.

[INAUDIBLE] >> [LAUGH] Right?

We've all been there.

Trying to talk to each other all the way through this,

agile does help with this a lot, is a really kind of important thing.

And it's very much the same with accessibility.

So with interaction, when you're thinking about interaction,

think about the fact that people are using lots of different ways.

To consume the content.

>> Interaction.

>> So if we take something like a search.

It used to be back in the day that

most people used a mouse to interact with content.

Except for people with disabilities who, more or less, used a keyboard or

some device that mimicked the behavior of a keyboard.

That's really not the case anymore.

We all use touch, we use speech, we use mice,

we use keyboards to interact with content and you can't really now tell

which people using which of those things has a disability and which doesn't.

So when you're thinking about interaction, keep things really simple.

We've got a search field up on the screen now.

Is there an obvious way to execute that search?

Is there a button that says Search, or do something?

That's good usability for everybody, but if you're talking about somebody who's

perhaps on the autistic spectrum, where clear instructions are really,

really critical, having that button with the clear instruction to search or do or

whatever is very, very important.

If you're not sure that that's gonna be feasible,

talk to the designers to make sure it can be built in so it's obviously a button.

Talk to the developers to make sure the space and

capability to put that button there.

Similarly, make sure it's clear that this is a search.

There'll be visual labels but you need to make sure that there are labels for

screen reader users.

People like myself who can't see what's going on.

Something like a search.

There isn't always real estate to put that, kind of, search text label in.

But, again, go talk to the developers to find out if there's ways in the code to

make those labels available to screen reader users.

Trust me, there will be.

But, if you just make assumptions at this point, you could be building,

Corners that the developers and the designers really can't get out of.

>> Slide 11.

Design.

>> When it comes to design, and I'm gonna come back to buttons.

>> Design.

>> Buttons just always come in for grief in these talks.

Make sure that, when you've got an element or

a control, that the visual affordances are really, really obvious.

If it's gonna be a button, make sure it looks like a button.

Now the reason I'm picking up on this is because quite often, what we find

is that something that looks like a button under the hood when it comes to the code,

is in fact a link.

If you happen to use a screen reader or another assistive technology like

speech recognition, those two things are fundamentally different.

If you've got a speech recognition tool and you're looking

at something that appears to be a button, and you say click on that button, but it's

actually a link under the hood in the HTML code, those speech commands won't work.

It's the same with a screen reader.

If you click on a shortcut to move to the next button on the page, but the button

actually turns out to be a link, everything pretty much stops working.

So when you think about the design, not only is it really good to make sure that

something actually looks like what it is, but again, talk to the dev guys and

make sure that it's actually gonna be what it appears to be under the hood.

>> Slide 12. Choice.

>> Give people choices.

>> Choice.

>> This was all from my blog, and here I've just got a dark and

light color theme switcher.

That's just one example of how to give people choices when you're thinking

about a website.

It doesn't have to be color.

It could be some other form of personalization.

Could just be making sure that there's a capacity for the content to be zoomed

using the browser's function without kind of losing legibility or readability.

But these are all just kind of tiny little things that you can do.

None of them are really earth-shattering, but by talking and thinking about how

people interact with stuff, you can start to make a really big difference.

>> Slide 13.

Communicate.

>> And all through this is just the necessity to communicate.

Keep talking to each other.

That more than anything is the most vital thing because between you, you have all

the information that you kind of need, but if you keep working in isolation, well

we've all been there and done that, it's just gonna make life a lot more difficult.

>> [INAUDIBLE] >> So, design.

Design like Chanel and you might of heard of this if you keeping up with this,

strive for beauty and elegance in the things that you build, but

understand that those things are pretty much different for

everybody who's going to be using your content.

So what I'm going to do now,

is just going to give you some incites into what it's like using a screen reader.

>> Slide once more from the top.

>> So back in the day, what used to happen when you accessed a web page with a screen

reader is that it would be like reading a text document.

There was no semantic structure, no information at all.

You'd just start at the top of the page and

pretty much read your way down a bit like this.

>> [NOISE] Chapters and

those [INAUDIBLE] can be used

to insert content into page.

In some situations, this technique is a useful thing to do, but

how to browsers and screen readers handle the generated content?

Using Schema.org with Microdata posted and code things on February 25th,

2015 search engines have ways of extracting meaning from content.

But they are prone to error because information on the web can be presented in

so many different ways.

Marking up information so it's easier for

search engines to index is a good thing to do.

And thanks to the vocabularies available from Schema.org,

it's also very accessible.

Time out notifications

[INAUDIBLE].

>> You still with me out there?

>> [LAUGH] >> So this is kind of why it gave rise to

the idea that if you use an assistive technology like a screen-reader,

it took you a hell of a lot longer to do anything than your sighted counterparts.

It really isn't surprising because it really was that painful.

Things have kind of moved on in recent years, though.

>> Slide 16, [INAUDIBLE].

>> What we've got now is browsers that

make a lot more information available to assistive technologies.

This has led to the ability to navigate by different kinds of elements, like this.

>> [NOISE] Heading level one accessibility support for

CSS rated content heading level two length visited.

Using Schema.org with micro data adding level two length visited.

Accessible time out notifications adding level two length visited.

>> So that's just using a quick navigation short key.

In this case, the H key jumps you from one heading on the page to the next.

In most screen readers now, there are shortcut keys for jumping between tables,

images, links, headings, paragraphs, div's.

Pretty much any HTML element you can think of.

So it's no loner necessary to just start from the top and hope for the best.

You can actually move around within a page, but all this is very,

very dependent on the HTML being present and correct underneath, of course.

>> Slide 17, [INAUDIBLE].

>> With HTML5, something even more interesting happened, and

that was the introduction of the sectioning elements like Main, Article,

Header, Footer, Aside, and Nav.

They add even more semantic information to the page that screen readers can

make use of.

>> [SOUND] Main region.

Accessibility support for CSS generated content article.

Using Schema.org with Microdata article.

Accessible timeout notifications article.

Navigation region.

Complimentary information.

Search region.

Navigation region.

Contend information.

>> So with those just HTML five elements, just pure HTML,

there's nothing exciting under the hood there at all.

The screen reader is able to use another shortcut key

to make navigation between each of those elements possible.

But it could also tell you now which part of the page you're looking at.

Whether it's related to search or navigation, complementary,

which is what maps to the aside element, or other bits of page.

So suddenly, a screen reader user has gone from having to read from top to bottom,

to now actually being able to get a pretty good overview

of the page as a whole to kind of holistic idea of all the chunks on the page,

which until HTML 5 came along, was pretty much impossible.

So things are definitely kind of improving as technology moves on.

>> Slide 18, Modus Operandi.

>> One thing thing to be aware of is if you're using all these shortcut keys as

a screen reader, like H to move from heading, P to paragraph,

or whatever they might be in each screen reader, there are times when you're going

to actually need to use those letters for the things that they're intended to do.

>> Tab. Search edit.

S-O-M-E-T-H-I-N-G.

Tab. Search button.

>> So that popping noise just indicates that, in this case,

the screen reader, it's Jule if you're curious, has switch modes.

So instead of intercepting the keystrokes and using them for quick navigation around

the page, it's actually passing the keystroke back through to the browser so

they can just type into the form field,

as you'd pretty much expect them to under any normal circumstances.

>> Slide 19, accessibility mechanics.

>> So how does all of this work?

Well there's quite a lot of mechanics that goes on in the hood of the browser.

Something that you'll almost certainly know is that when you load content

into the browser, the browser will create a document object model.

Dom Tree, it's a hierarchical representation of the content that

contains a whole bunch of information that you can interact with,

manipulate, do all sorts of things to.

>> Slide 20.

>> What you might not know is that the browser also creates

an accessibility tree.

It takes a whole bunch of information from the DOM, and

creates an alternate hierarchical model.

And this model,

this tree contains information that's used specifically by assistive technologies.

And there's all kinds of information in there.

>> [INAUDIBLE] Role, role.

>> There's information about the role of each element on the page.

All HTML elements have implicit roles.

So onscreen, we've just got a check box, and input with a type="checkbox".

>> Bullet label equals.

>> And that type="checkbox" tells the browser that this is

an input with type checkbox.

That information is picked up in the accessibility tree and

used by assistive technologies, so

a screen reader encountering the control created with this code would tell the user

that this was a checkbox, and that's the role of it and its purpose if you like.

>> Slide 23, 23. >> You also get information about

the state, in this case we've got checked attribute on input.

And again, that state information is picked up by the accessibility tree, and

made available to assistive technologies.

So the screen reader would not only know that this was a check box, but

it would also know that it was in the checked state.

>> Slide 24 >> Lastly,

the information in the accessibility tree contains a whole bunch

of accessibility properties about an element.

The most common of them is the accessible name for an element.

Which is basically the way that you tell,

in this case one check box on the page from the next.

>> [INAUDIBLE].

>> [NOISE] We've done it in this case by just using the label element and

hooking it up to the input using the foreign ID attribute pairing.

Really, really basic 101 HTML.

But now, a screen reader coming to this page will know that the name of this check

box is Tequila, as opposed to any other that might be on the page.

Speech recognition user for now could say, uncheck the tequilla check box.

Just identifying it by name, in a way that you identify a person by a name.

>> Slide 25, Accessibility APIS.

>> So all these works thru Accessibility APIS.

Form has one.

Windows, Linux, OSX, IOS, Android.

They all work at the operating system level.

So the idea is that if an assisted technology wants to know

something about an interface, it gets the same information back whether it's asking

something at the operating system level, something within an application interface,

or something within the rendered content within a browser.

>> Slide 26, Design like Brunel.

>> So, how does all this work in practice?

We're going to take a bit of dive into some code now and pull some of this

together to give you a working example of how the accessibility API is,

the accessibility tree all come together to makes things more accessible for

screen readers, in this case.

>> Slide 27, Skeleton HTML.

HTML. >> So

we're gonna start by building a custom disclosure widget.

Yes, it's always better to use a native HTML element because you get a lot

of accessibility goodness built in, but, with the advent of JS frameworks,

where unfortunately the output code is not always created by people who understand

good quality semantic HTML, because we get stuck where we need to remediate legacy

code that was built in goodness knows when We're just gonna take a worst case

scenario, and that's starting with a span that we're gonna use as the control for

disclosure element or widget, and

a div that's gonna contain the content to be disclosed.

>> Slide 28.

Using a mouse. >> If we imagine we just throw a bit of

CSS and scripting at it, this is how it would pretty much work for a mouse user.

>> Using a mouse.

So, all well and good.

Things open, they shut.

Content appears.

It's all pretty good.

Slide 29.

Using a keyboard. >> If you looked at it on a keyboard,

this is what would happen.

That's it.

Nothing.

Absolutely nada.

A span is not an interactive element, so you can't focus on it with a keyboard.

You can't use the tab key to get to that control.

So, for a keyboard only user, that's it.

Game over.

Bother shouting.

If you throw a screen reader into the mix, it is actually possible to focus on

that control because there are ways to do that without using the tab key,

but this is the net effect.

>> That's it.

Just the one word.

There's no indication that this is actually a button, or

anything more exciting or interactive than a piece of text.

And that's because div and span, or

span specifically, isn't semantically neutral element.

So, in the accessibility tree, it's really just treated as a piece of plain text.

So, we need to start adding some more information into the browser's

accessibility tree to give screen readers something a bit more concrete

to deal with.

>> Slide 30.

Add role.

>> And we're going to do that using some Aria attributes.

Accessible rich internet applications.

Version one is the current version with respect from the W3C.

So sets of attributes that you can apply to HTML markup and, increasingly,

to SVG, as well, that lets you manipulate, or

change the information that's available in the browser's accessibility tree.

Aria doesn't change functionality,

doesn't add behavior, it just changes the semantics of what we're dealing with.

So, the first thing we're going to do is use the Aria role attribute

with a value of button.

And that gets applied to the spam and will basically, in the accessibility tree,

tell assisted technologies, quit treating this like a spam, treat it like a button.

It's really important to stress though, this doesn't change anything in the Dom.

It's only in the accessibility tree that stuff changes.

Slide 31, add to index, full printer.

>> We're gonna add tab index with a value of zero.

>> Bullets bullet.

>> And we're gonna do that on the span as well.

That's gonna make it keyboard focusable.

Tab index with a value of zero will place this into the tab order of the page

based on the elements location in the dom so it keeps it really natural.

It'll just slot it into the natural keyboard order of the page so

it's a good way to do it.

>> Slide 32, add focus impulse, play button.

>> We're then going to add some focus visuals.

So now you can focus on it with a keyboard.

It's really important to know that you focused on it with a keyboard.

So we're just gonna duplicate the hover styles that were in place already and

just make those work so that when you tab onto that control you get that same

visual change in appearance that lets you know exactly where your focus lies.

>> Slide 33. Add event listeners.

Listeners.

>> We're gonna add in some event listeners, so

there's a good chance already that the event listener for click is in place, but

we also need to listen out for keyboard events.

We're gonna listen for the key down event as opposed to key press or

any other because the expected interaction for a keyboard user and

a button is that you can use either the space key or the enter key to activate it.

If you're using the button element, the native button element,

that's what you get built-in by the browser automatically.

So we're gonna listen for the key down because we need to capture the key code,

so we can identify which key's been pressed and add in some functionality.

And all we're doing here is just listening out for those keys.

If any other key is pressed, we're just letting them get on to do their thing.

But if either of the key codes, 32 or 13,

are identified, then we're just gonna make sure that the rest of the function

that we need to execute is carried out based on those key commands.

Slide 35. Add Aria-Expanded Expanded.

>> We're gonna come back to some Aria now and add in the Aria-Expanded attribute.

Again, that goes on the span.

[SOUND] >> Bullets bullet.

>> And what this does is indicate the state of the disclosure widget.

So we'll set it to false initially on the assumption that the disclosure widget

is closed.

But as the widget is activated, the script will toggle it to be true and that'll just

inform the screen reader whether the thing is open or closed in its current state.

Slide 36. Add state visuals.

Visuals. >> Then we're going to map some visuals to

that as well because if we're going to make custom faces accessible to everybody.

It's not just about us screen reader users,

we need to think about you sighted guys too.

So, we're going to add in an icon that just flips over depending on the state and

we're gonna bind that to the current value of the area expanded attribute.

Using attribute select is a really neat way to keep things neat and tidy.

Stops you having to clutter up stuff with class names in your HTML.

Actually, I have to thank Hayden Pickering, one of the other speakers here

this week for that particular tip, which I've become extremely fond of.

>> Slide 37. Add Aria-Controls.

Bullets equals quotes.

>> We're gonna add in some more Aria, the Aria-Controls property, and we're gonna

use this to create a relationship between the control button and the content.

Bullet id Mismatch >> When you look at this and

you activate the widget, you're gonna know that something has appeared.

It's gonna be really obvious.

But if you're using a screen reader and

you hit the button, it's not gonna be obvious that some content has appeared.

What the Aria-Controls attribute does is create a relationship that will tell

the screen reader to inform the user that they can move, take a shortcut,

to the content that's being controlled by the button.

So, it just sets up that relationship and enables a navigation mechanism for

moving to it.

>> Slide thirty-eight.

Add Aria hidden. Bullets list.

>> We're going to add in Aria-hidden and

we're going to do that in a couple of places.

We're going to add into the span where the icon is shown and

also to the div where the content is.

[SOUND] >> Bullet divides bullet.

>> What Aria-Hidden does is remove content completely from the accessibility tree.

So as far as the browser's accessibility tree and

any assistive technology is concerned this content won't exist.

So we'll set hidden to true on the icon span because there's no real need for

a screen-reader user ever to need to know about that icon.

We'll also set it on the div.

We'll set it to true initially because the content will be hidden.

And then as the widget is activated, we'll toggle it backwards and

forwards between true and false.

Slide 39.

Add more state visuals.

Bulletin=quote.

>> We're then going to add some more visuals in there and

that's just making sure that the content is shown in high based on the CSS.

You might be asking why user are hidden and something like display none.

It's really belt and braces techniques.

If we don't need the content to be rendered in the accessibility tree.

There's really no point in making it be there.

So, Aria hidden just kind of takes that out of the equation.

There's also kind of an edge case where someone might not have CSS enabled.

It's fairly slim edge case these days, but

the RA hidden would still just make sure that the content was

tucked away from assistive technology users, even if that was the case.

Slide 40. Add functionality.

Function title disclosure.

>> Lastly, we're just going to add in some functionality, so

we're going to make sure that the whole thing works.

So if someone activates the button and the script is executed,

we're just going to toggle the states of all those Aria attributes,

the Aria hidden and the Aria expanded.

And in doing so kind of kick off the cascade that ties in the CSS to create

the the right visuals, and hopefully bring the whole thing together.

>> Slide 41. Using the screen reader.

>> So, [LAUGH] after all that little lot,

this is the difference that it makes to someone using a screen reader.

>> Using the screen.

To feel the button collapsed.

To feel the button expanded use Jaws

key/g+Alt+M to move the controlled element.

Move the controlled element.

Makes me happy...

[LAUGH] Trust me.

Tequila does make me happy.

But [LAUGH] what should hopefully make us even more happy

is that we've still got the disclosure widget that, on the face of it, looks and

behaves and appears exactly as we originally intended it to but

now has a whole bunch of accessibility built in under the hood

to make the experience more inclusive for many more different people.

And that sort of really comes back to this whole idea about designing

like we give a damn.

Go out there, build the thing you want to build, create the thing you want to

create, be as inavertative and outlandish and mad and crazy as you can possibly be.

But know that there are ways that you can make things accessible.

If you're not sure where to go from here, as they say, come and shout me afterwards.

Questions now, or ping me on Twitter, but myself and

plenty of other people out there in the accessibility world are really happy

to help answer you and point you in the right direction.

Slide 42. [INAUDIBLE]

>> Thank you.

>> [APPLAUSE] [MUSIC]