So, hello. Like he said, my name is Cassidy Williams.

There's only two S's in my name, but that's okay.

You can say Casssidy Williams.

And so I'm gonna be talking with you about accessibility in the browser today.

So like he said, I'm a software engineer and developer of Evangelist at Venmo.

And it's very fun.

I'm normally a front end dev,

and I'm on the back end team now and so, experimenting with new things.

So let's get started.

So, the internet is great and I think all of us know that.

And to illustrate that, let's look at this cool website.

It's nooooooooooooooo.com and you can press this button.

Oh no, volume.

>> [NOISE].

>> Oh, that's so great.

So it's super great.

But it's great if you can see the screen, and

if you can use the mouse to actually click that no button.

And if you can hear the audio that actually plays when you click that button.

So if you have no disabilities of any kind.

The web has so

much potential for everybody, including people with disabilities.

Most studies find that about a fifth of the population actually has some

kind of disability.

But we aren't really accounting for them.

Very few businesses, very few people out there actually write web applications that

support people who use assisted technologies.

So what we're going to talk about today are is the semantic

web the WAI-ARIA specification and accessibility checklists for

your projects, and then any questions you might have.

So, the semantic web, it's kind of one of those buzz words like synergy.

Semantics is the science of meaning.

It's assigning states and rolls and

properties to user interface and content elements.

And so, two kind of things about it that I'm going to talk about it are just new

HTML5 tags and then the role attribute in particular.

So, HTML5 semantic tags are probably some of the easiest things you can add to

your web applications and your web sites to make them more accessible.

I won't talk about this part too long cuz there's a lot to get to but,

basically with the magic of CSS today, anything can look like anything.

A link can look like button, a list can be a control interface.

Whole pieces of artwork can be done in a single div.

I don't know if you've ever seen a.singlediv.com, but it has all these

pieces of artwork that are done just in one div, and it's just the magic of CSS.

There's so many opportunities with it, and it's great,

but let's actually look at a.singlediv.com with a screen reaver, reader.

So let's go over here.

[INAUDIBLE] That.

Oops, okay.

So this is a singlediv.com.

Whoa, these are all a single div, that's so cool.

If you do command F5 you can turn on a screen.

>> Voice over on Chrome.

A single div window.

A single div HTML content.

>> Okay.

>> Visited link, Lynn Fisher.

Link, tweet.

Leading HTML content.

Back button.

>> So, I don't know if you caught that but there's the link to Lynn Fisher,

who made it, there's-

>> You are currently on a button inside of the toolbar.

>> Stop. >> To click, voice-over off.

>> So, [LAUGH] sorry about that.

So it said, oh there's a link to Lynn Fisher.

Okay and then if you hit tab,

because that's how you often navigate through a page if you need to.

There's a link to Lynn Fisher, there's a link to tweet, and

then it said end of HTML document hit the back button, and that was it.

There's so much content on this page, but a screen reader couldn't see any of it.

It just saw that there were two links on the page.

And, I mean, I don't wanna, you know, take a jab at Lynn Fisher.

Like how dare you make single div art.

But it, it would be great if you were able to say put like a fig caption or,

or some other caption tag that is in HTML5.

So that way, even if it was just someone who said oh, cool,

there's a single div that has a cupcake in it.

The, it would just make things so much easier for people who are just

browsing the internet but can't actually use it the way most people do.

So that's important, if she had a nav tag, so that way she would know how to

navigate the website, a fig caption, something like that.

Mm okay.

So, sorry Lynn Fisher.

And then the next thing we'll talk about is the role attribute.

And what it does, it provides a programmatically determinable relationship

between specific content and

that's a big part of accessibility, just that word relationship.

Because everything should be able to flow together and be relatable to each other.

So let's just say I have this cat named Lola who's been up to no good.

She's dressed up for Halloween.

I don't have a cat but I can dream.

So we have an image tag, we have that handy alt attribute and

then we have a paragraph saying Lola has been up to no good.

And clearly, oh, this is a caption for this cat.

This is so great.

But if we were going through this with a screen reader, or some kind of

assistive technology, we don't know that these two are related at all.

They are completely separate tags.

So, what we can do is use the roll attribute.

And so we can put, it looks the exactly the same to all of us, but

what it does it puts all of this into a group.

And then actually makes this one whole thing with an image and

then a caption and it's all related to each other.

And so when someone's actually going through there's an accessibility tree and

it has all of these different nodes that are related to each other in some way

based on all these these accessible attributes and states and properties.

And so all of these are now in one node on a tree, and so

someone who's going through the page with an assistive technology can see oh,

Lola has been up to no good, that's related to this cat.

It looks the same to, to us, but for

someone with a screen reader, it makes the world of a difference.

So again just to emphasize,

adding a role will not make an element act or look differently for anyone.

It doesn't change the behaviors,

the states, or the properties of the host element in anyway.

It just changes that accessibility tree.

And so it doesn't harm anyone, it just helps some people.

Which, why, why not do it, then?

So let's get into this WAI-ARIA specification.

I'm not sure if that's how you pronounce it, that's just what I say.

So it's W3C's accessible rich internet applications spec.

So it's, it's just this whole specification to add to

your web applications to make them more accessible.

It defines oh, it defines all, all kinds of different properties

and states and just things to make your web applications flow a bit better.

So there's a contract model with the browser's accessibility APIs.

And this is also on the W3 website.

I just made it like, prettier and big so

you guys can see it without too much hassle.

But so there's the user agent, which everybody knows it's, it's the browser DOM

which has all of the data and the UI, all of the divs and tags and everything.

And then there's JavaScript which is kind of a controller for the web application.

It produces the widgets on the page it's all very event driven.

And then there's the accessibility API that works directly with that.

And so it has that role that we just talked about which

handles widget types and

navigation, throughout the page and then it has different states and properties.

And the different states and properties which are a part of the specification

defines relationships and values and just live regions on the page.

And then assistive technologies work with both of those and it's, it's all working

together to make a seamless application for someone who is using those pages.

So before we dive too deep into it, there's four rules, for ARIA use and it's

not like absolutely you must do this, but it's like parlay, there good guidelines.

If you look at the W3C website there's actually five rules, but

one of them is not as relevant, so we will just talk about four of them.

So first, if you can use a native HTML element or

attribute, then do so, because it's built in.

You don't need to repurpose it and add an area role or

anything like that, just use the original.

There are exceptions to the rule.

For example, if there's design constraints with that particular element

you don't wanna change everything around that just because the element has to

be styled as required.

But besides that, generally keep it as native as possible,

because almost all HTML elements natively have some sort of accessibility support.

And it's usually for

custom controls that you do have to worry about adding these rules.

For the second rule don't change the native semantics, unless you really,

really have to because again, it's, it's great if it's built in.

And so, for an example, if you have a heading and you want it to be a button.

For, for whatever reason.

Just use a button tag and the h1 tag rather than adding a roll to the h1 tag.

Because it'll just keep it seamless between both, expect for

between accessible users and standard users.

That doesn't add any changes here.

Then the third rule, all area controls should be usable with the keyboard,

because not everybody can click a mouse or touch a screen or anything like that.

If you make a widget where a user can click or drag or scroll or

swipe or slide or some other thing that sounds like a song.

It should be, you should be able to navigate with the keyboard,

just because that's how a lot of assistive technologies work.

And then, the fourth rule, all interactive elements must have an accessible name and

that kind of like that relationship word that I was talking about before,

you should be able to have a name that relates everything together.

And, so, for example, we have an input with a label.

We've mentioned that I like Taco Bell, I really like tacos.

So we have this label and

an input and, like, to a standard user it's a label for that input.

It makes sense.

But, we don't know the relationship if you're using some sort of assisted

technology, so just label for taco, and then that, the input has the ID taco.

It makes it much easier for someone who is using assistive technology and

doesn't know the relationship between the different elements on the page, and

it just works again with that accessibility tree.

Okay.

Let's go through some examples.

There's so

many different roles in properties and states that come with this specification.

I could talk about it all day, but I know you guys want lunch.

And so, I, I'll, I'll just, I'll just cover a few.

And so, this one, it's a pretty standard and simple one, describedby and

it specifies some sort of hyperlink to content that describes an object.

And so, if we go back to my dream cat, Lola if you have your image and

then you have a div that describes Lola.

And this, this div could be anywhere.

It could be very far down the page it could be on a different page entirely.

You want the description to be available for it, but

you wanna build that relationship.

So you can add this describedby right there, and then just link to that ID,

and you can link that, it's just like an href and an anchor tag.

You can link it to a different website that might describe like very

in-depth Lola's costume and grumpy face.

Or you could just link it to another div on the page, and

again, it builds the relationship between the different elements.

So that way someone who's using assistive technology can see that relationship and

understand it.

Okay.

And there's a great example from University of Illinois that I'm gonna use

next because the, they, they did a really great job with it.

Before I open it up it uses two different roles throughout this page.

It uses application, which covers the entire like module of the application, and

it has buttons in the application.

And it's going to be a tool, a toolbar for a text editing area.

And for the states and

properties it has controls, so it has different sets of controls.

It has pressed for the buttons and then it has labelledby so

labels for each of the buttons.

And so, let me go to that page right here.

Okay, cool.

Let's see if we can do that, there we go.

So, this is, this is the page.

It's pretty simple.

Now what I'm going to do is I'm going to turn my screen reader again.

Hopefully it's not to loud.

>> Voiceover over on Chrome, overview example, Toolbar Example one.

Window.

>> Okay. >> Link, overview list to our

visited link, font larger, toggle button.

>> So the label on this button is font larger, toggle up.

>> You are currently on a toggle button.

>> Shh. >> Inside of a toolbar item palette.

Choose. >> And

so what you can do is move around just with the keyboard on this page and

then press the space bar and it just works with this application.

>> Font smaller. >> Which is great.

>> Toggle italic.

Selected toggle cold, toggle button.

>> And, it's a lot of of talking I'll try to shut him up a little.

But then you, again, you can use all these different controls.

You can actually type in here and everything is, is keyboard editable and

this entire page is just a great application of that for

moving around the different controls.

And again the screen reader was able to say exactly what everything is.

And so it was able to define the labels, this is toggle up, this is toggle down.

For font size, this is italics, this is bold.

And if I were to inspect element,

I'm not going to because screen resolution is weird.

You could see it's really just adding those little values.

For areas described by or area the this is a control area.

And you can tab in between all these different roles and

it just flows very seamlessly with the page.

Okay let's go back.

cool.

So, let's talk about your projects.

There's a sort of accessibility checklist that you

should cover whenever you're making your applications.

Oh, I left that screen-writer on.

[LAUGH] Sorry.

Ooh.

Okay.

Shut up please.

Okay, cool.

So, accessibility checklist.

So, visibility, use, when you're making things visible and invisible on the page,

use the visibility and display properties or the hidden attribute.

Don't use things like z-index or

opacity or placement for hiding things completely or just hiding them on the fly.

Because that's not always going to work.

And someone with a screen reader might say huh,

there's like a circle that's off the page, I wonder why it's there.

Just make it, make it hidden.

It's, it's easy that way.

And also try not to override too many of

the browser's default behaviors because that's just say you override zoom.

That means someone who isn't able to zoom in on the text on your page to

read it better.

They might not be able to see everything that they want to see or

read everything that they want to read.

And so again for

design it's one of those things that you kind of have to find a happy medium for.

But try not to override too many things so everybody can use your page.

I haven't talked about this one too much.

But, Color there,

there should be a certain amount of contrast with your pages.

Which we could, there's all kinds of cool checkers on that.

This is my favorite one, where it's just a Color Contrast Check.

And, it'll say which ones are actually compliant for accessible things.

And so if I were to make this really, really red suddenly, no.

It's really bad to have green text on a red screen for people who are color blind.

And there, it's, it's nice to be able to check different colors against each

other and everything and make your applications easy to see for

as many people as possible and make in compliant with these.

Okay, let's go back.

Come back.

Okay, cool.

focus-ability.

We kind of talked about this a little bit,

but, everything on the page should be able to have focus.

You should be able to navigate the entire page, with tab or

just different arrow keys and everything and

you shouldn't have to be able to moves your mouse, use your mouse for everything.

And then if a control on your page isn't standard, it's not a button or

a link or list item or a navigation thing.

They should have an appropriate area roll attached to them, so

that way someone who is navigating your page, again, with a screen reader or

assistive technology can navigate it easily without having to say oh,

well, I guess there's nothing else on the page and that's it.

And then, State Changes,

This is another thing that you should be on your check list.

Standard controls have this taken care of pretty well, but then for

custom controls it's good to have solutions.

And so aria provides that with aria-checked, aria-pressed, et cetera, and

one thing that's important here, is being device independent.

It's really hard for someone if, using your applications if,

all you use is on key down, or on mouse down, or on mouse over.

Instead use something like on focus, or

on blur, or on submit, or something that's device independent.

And so when, whether they're using a phone or a desktop or a screen reader or

whatever different technologies that they're using.

It's again, device independent, and anybody can use it.

Kay, so there's a cool, a few developer tools, and for

some reason, the links aren't showing up, but these are all links.

And there's different things that you can use, that way you can work on

these sorts of applications, so Fang's Screen Reader Emulator,

that one was featured on Mozilla's website for actually emulating a screen reader, or

you can just use the native one on your computer.

I have used that for messing around with this presentation.

And there's, best practices thing.

For WAI-ARIA and that's just on the W3C website.

You can just look up WAI-ARIA best practices.

It's the first one that shows up.

And it talks about all of these rules a bit more in depth and

has a few more examples, showing screen readers or

pop ups of that sort of thing that show the best ways to use that.

There's that color contrast checker that I just showed you.

I'm going to be posting all of this on the internet so

if you don't want, if you want to just take a picture I can show you later.

But that color contrast checker just having some sort of

contrast checker just so that way you don't use funky colors and

make people not be able to see what you've made those are really great.

And then there's a lot of testing services.

Mozilla recommended this, Tanaguru's Automated Testing Service but there's

a bunch of accessibility testing services out there where they'll just go through

your applications and say, oh, these are some of the changes you can make or we can

automate this for you and actually help you build more accessible applications.

And then there's always html5accessibility.com which has

a bunch more rules and ideas and help for getting there.

So again accessibility, it helps some users and it doesn't harm any.

So there's really no harm in actually doing it.

And it's good to make the web accessible for everyone.

Thank you.

[APPLAUSE]