We'll try and ask the kind of questions that don't induce nose bleeds in this section.

Awesome.

So there's a few themes that come out there straightaway.

But one of the things that I'm trying not to sound like a bitching developer when I ask the question, because there's a lot of attributes there, a lot of techniques that we would probably foster that it's hard to make the argument to the designers that we're working with, or the people signing the checks for the sites.

And I know that's the wrong attitude.

But it's a difficulty, right.

And you mentioned the turning off the scaling.

Yeah.

I see now a lot is being used as a bit of a hack as a way to make some of the layouts possible that are being asked for.

So before we get into anything technical, have you got any good tips, or have any of you guys got any good tips on pushing back on that and saying, here's some data about why we should avoid some of those kind of design choices or things that are going to lead us to do that.

Is there good data available for that? Or is there other good ways of making that argument? What was the fine for Target for not having an accessible website? It was a lot of money.

So Target paid $6 million, plus $4 million in attorney's fees.

That's really good data.

Right.

Yeah, money talks, doesn't it? Money does talk.

And sadly, that is big motivator.

But it's really just user pain.

I mean, if you try and pull up any news site and you-- "New York Times," for example-- last time I checked, they had taken their desktop styles, made it responsive, so things are now viewable in one tiny column.

But the text is so small and so faint because of the color contrast and the size, that all of a sudden, if you've presented zooming, you can't read it very well.

So some of it is anecdotal.

Some of it is the legal risk.

I think all of those things together should be enough to make people care.

Yeah.

And I don't know, maybe different people have different experiences in projects.

But I often find that some of these arguments seem to fall to the developer on a project to say, well, hang on.

Have you thought about this? And I know the UX teams are getting-- that's what they focus on as well.

But often some of the things to do with color contrasting you just mentioned.

And to do with, oh well, it fits in this nice view port now.

So that's fine.

Those seem to tick the boxes.

And it's developers who raise those things.

So having access to that kind of data in that argument is kind of critical, I think, to make that point.

I mean, I think the best way to argue it is the dollars, because that is who our boss's boss-- that's what they care about.

But the reason we're talking to the developers and not to our bosses- boss is when you can't get our boss's boss into the same.

If you actually want to talk about something meaningful.

Did I just say that? I did.

But developers actually care.

So it's converting-- maybe a developer didn't know about it in this room.

But actually hearing about it, they're like, wow.

I never thought of that.

But the easiest way to make something accessible-- like this talk I'm developing, which I didn't do here because Marcie covered everything that I was going to do in my original talk with that website that I refactored in 1,000 lines of JavaScript.

The reason I was able to refactor it into 1,000 lines of JavaScript was I used native elements.

And I no longer had to use ARIA support.

So when you use the span for your checkbox, I was cringing, because I'm kind of like, just use the check box.

Use the checkbox.

Or use a select.

And then if you don't use a select, what is the equivalent of a select? Almost is a radio list, because you can only select one.

So just thinking outside the box, because we have these elements and they're accessible.

And so when I did this-- I did a carousel using radio buttons.

And to make this entire carousel accessible was four lines of JavaScript.

Who here has developed a carousel at all? And then in less than 5,000 lines of JavaScript? And then under 10.

So if you actually use native elements, it will do what you want to do.

You not longer have to do key up, key down, key right, key left, tab.

cause it's all taken care of.

Yeah.

I mean as soon as you start reinventing what the browser's already done, you're fighting a losing battle.

You are.

To piggyback on what Estelle was saying too was, I don't know any developers who believe in doing a bad job.

Anybody here like doing crappy work? So forget about what the executive has to say, right? And like Estelle was just saying, yeah, there's probably a lot of people in the room who don't know a lot about accessibility.

But ultimately our decision whether or not we want to do a good job comes down to us.

And we could put forth some of that extra effort.

And really it can start with basic stuff.

Form field labels is huge.

People need to know is converting a visitor to a customer is based upon their successful submission of a form, putting form field labels on there is like a no-brainer.

And you're doing a good job.

And so I choose to sort of walk around the executives who want to be naysayers, and just do it anyway.

And I think sometimes those are steered by an aesthetic direction that the visual design team often will be going for something in particular.

And that's not to slight visual designers.

Are there any designers in the room? Visual designers in the room? All right.

They're going to come and beat the crap out of me.

But that is a regular tension, right, trying to satisfy all of those things at once.

And yes, I think that the development team can then bring something to the table there.

It doesn't have to be to just like, implement this PSD space.

Right.

Yeah.

For sure.

You were talking-- so I love seeing examples of screen readers.

And it's so enlightening to see that.

A few people have been asking about how best to test with screen readers.

I know that I think you both have used examples of the voiceover in OS X. But

is that good enough for testing? Is that a good enough insight? Or do you need to go further? It's a good start.

The reason I like using voiceover is because there's text output.

And so it gives you a good example for teaching.

But it's not the most used screen reader.

There's a great survey from WebAIM on screen reader usage, both on mobile platforms and desktop, jaws, NVDA, NVDA being open source.

That makes it a bit easier to get your hands on it.

JAWS is a very used screen reader on Windows.

I didn't know until maybe a year or two ago, that you can use jaws in 40-minute mode for free.

It will just quit after the 40 minutes.

So if you're using it to test, you can still get your hands on the software, which normally is really expensive.

So there's tools out there.

I tweeted a link just to answer one of those questions that WebAIM has really good tutorials on, what the key commands are.

And how you would navigate.

And so that's a really good resource if you're wanting to get started with screen readers.

So let me just-- because I don't actually use screen readers.

And I should.

But I don't.

And so I think most people here are like me.

And they're like, what is the easiest thing to do? So I do something easy.

And it's not 100% accurate.

But it gets me 90% of the way there without annoying me, which is-- I develop in Chrome, because it's easiest for me to develop in Chrome.

I like their developer tools the most.

And Voiceover is meant for Safari.

It's not meant for Chrome.

However I leave Voiceover on with just the text showing.

So I turn my audio off.

And I have the text there.

You saw the tech show up in that little black box with the white text with the whatever.

I'm jet lag.

Hello.

Cognitive overload.

And so I just have it on all the time when I'm developing actual forms and stuff.

So it's reading it to me.

And I can see what I'm doing.

And I'm like, oh, I forgot that.

And then I use a few CSS tricks, (which is img)not parentheses, brackets, Alt. Type that out.

She got it.

There's another hot key for that.

And then like border red, 20 pixels.

And then if I have an image with an Alt attribute, it's 20 pixels, red border.

It's like, hello.

And then Alice Boxhall from Chrome, or from Google.

She developed an extension for Chrome.

And I don't know-- it's supposed to be becoming native in the developer tools.

If it's not there yet, you can just add it on.

But it's in your tools.

And it tells you what the text that's going to be read is.

And then the Paciello Group and DQ, their websites have a lot of information.

Yeah.

There's tools that you can use to help you find these things.

Like if you respond well to a checklist of things wrong, you might benefit from a tool like the Chrome Accessibility Developer tools.

Karl works on a tool called Tenon.

I work on another tool called Axe.

You have your choices that you can use to test things, so that then you have something to react to before you're sending it out broken.

As a developer, you can arm yourself with this knowledge.

But using these tools that will help you from having to pore over source code and figure out if you've got an Aria attribute wrong, or if you used it incorrectly.

Because frankly, we can't hang on to all of those details.

So using a tool to help you find problems is a good recommendation.

And so the accessibility tree was new to me.

I have to hold my hands up.

How much should we as developers understand the accessibility tree? Where is it reasonable for us to take our responsibility? I mean, should we understand that it's there, and it's doing a job.

And there are principles that we should do that take care of that.

Or should we understand the accessibility tree in a bit more detail.

What's reasonable, would you say? I think with a reasonable thing would be to start with a screen reader, because that's the end goal of that structure is to provide information to a screen reader.

I just happen to b e really geeky and nerd out on that kind of stuff.

So I thought it was interesting.

But if you're just getting started with it, it's important to know that that thing exists.

Obviously, that was what my talk was about.

But I think getting started with a screen reader so that you know why the accessibility tree exists.

That's a really good place to start.

I think that people should understand the Dom more.

Or the principles of object-oriented programming.

In that a lot of people think I've created some HTML and CSS and JavaScript.

And I'm doing all this cool stuff, when the reality is that you're actually making a polite request to the browser to say please implement the proper objects on the screen based upon this text file I've sent you.

And towards the point that Marcy had made in her talk was, some of the stuff.

You get the accessibility for free.

You know, that long-winded description that I gave of the select element, all that stuff is based upon different browsers' implementation of those objects.

And so there the Dom specifications is just a series of interfaces that the browser vendors then implement.

But it implements it in a way that exposes all sorts of important accessibility information.

What is this thing? And what does it do? Right.

It's the name, the state, the role, and the value of the object.

And the accessibility tree is the manifestation of that, really, is the part of how it communicates all of this information to the assistive technology.

And I think that that closeness to the Dom, and understanding the Dom, is really important.

I mean, I kind of classify myself as a bit of a traditionalist when it comes to building stuff on the web.

And some people might call me a bit of a fuddy duddy.

That's fine.

That's actually your nickname.

Yeah.

One of my many nicknames.

So I really like seeing that your a contributor to angular, but then you've got such focus on accessibility.

And maybe this is just a complete misconception on my part.

But I kind of think of angular tools like angular as an abstraction away from the Dom that means that people often have less of an understanding of the Dom, to your point.

And so maybe it's unfair of me to think of tools like Angular as something that can get in the way of accessibility.

Is that fair to say that that's-- is that a fair criticism? Or have I completely mischaracterized those kind of tools? I think Angular made-- it's a tool that people who might not be as familiar with the Dom.

Making it easier to build really rich JavaScript apps, where sometimes you don't have the documentation or support that you would need to learn what is this thing and what does it do.

And so I think the challenge is that we're bringing people into web development who maybe don't know all of those details.

And so as framework authors, we have a burden to create documentation that teaches people how to do it right.

And I think that is an ongoing battle.

But I think that you know, people are starting to learn from like angular one.

There was not very good documentation for that.

It came in later.

But that ship had sailed in a way that we taught people how to do it incorrectly.

So part of the effort moving forward with Angular II is to try and make that more clear how to do it right.

And instead of automatically fixing it for you with things like ngAria, putting more effort into test tools and things that become part of your development workflow to tell you that you did it wrong.

Instead of just hoping that the module will fix it for you.

Makes sense.

We're going to have to leave it there, because we're out of time.

So thanks once again.

Thanks, everyone.

To Carl, to Marcy, to Estelle.

[APPLAUSE] You can stay there if you like.

Or you can--