I'm going to talk about accessibility very quickly. As we've just seen, sometimes it's not very easy to see the screen you're working with,

so particularly relevant today. I really liked what Tom and Yehuda were saying in the keynote about being able to benefit from everybody using the same technology, structuring their apps in the same way, and not having to be experts in very specific aspects of the technology, being able to use high level

knowledge from the community and really take advantage of that. And I think accessibility is one of these topics. You don't have to know a lot about accessibility to benefit from work that people are doing in the community in this area. So accessibility is a pretty broad topic, and I'm just going to talk about screen readers today.

So alternative title for the talk could be Ember with Robot Voices. Normally, we get a lot of structure from the DOM in terms of being able to give the content of the page to the user by reading it out from the browser. In the case of Ember apps, we do so much manipulation

through data bindings and through transitions that sometimes the content changes on the page, and although it's visually there, it doesn't actually make it to the screen reader. So if you're visually impaired, you just don't know about the changes that have happened. I'm Ben. I work at Zesty. We're a corporate wellness company in San Francisco,

and if you want to come work with us, do talk to me after the day. We held a hack day at Zesty and had a bunch of people in, and we made ... Thank you. Loads of really just great contributions, one of which was with Nathan Hammond and I

prepared on producing an add-on that you can install in your apps that will help improve the accessibility for your websites. So we're aiming to build a collection of tools here that just really help you out making your apps more accessible.

In this particular case, we're looking at improving how navigation happens for people using screen readers. So how a screen reader works is it goes through your page, starts from the top, and just reads out all of the content to you. And then when you navigate, it will then start again from the top

and then read out the whole page to you. So in the case of Ember apps, if we have nested routes, that's really great because we can just look at the content that has changed. We actually used the same code in Liquid Fire to detect what the state of all the outlets in the application tree look like before we made a transition

and what it's going to look like after the transition and then detect all of the content that has changed. So in this case, if we're looking at Ember Observer, we're searching for an add-on that we want to see. When we actually pull up the add-on page, it's just that section there about the content of the add-on that we want to be read to us.

So once you've installed Ember A11Y, all you need to do is replace your instances of outlet with a focusing outlet, and then it should just start magically doing everything for you. And in particular, we were using Ember Observer

to prepare an example installation for this, and it was super easy to do, and it's actually now been merged into master, so you can, in principle, find your favorite add-ons with your eyes closed. I'm going to show you a bit of what using a screen reader sounds like

and what that navigation experience is like, and we should notice that when we open the page for the add-on, it doesn't start at the top bar again. Search for add-ons, maintainers and categories, insertion at beginning of text. Search for add-ons, maintainers and categories, edit text. You are currently on a text field. Two button, end of bed, heading level,

heading level, list two at eight, visited link. Ember A11Y, a collection, press. Ember A11Y, a collection of tools to build accessible Ember applications. So yeah, crazy robot voice. So not everybody uses,

first of all, actually, in terms of getting this to work, there was a little bit of hackery around. The main piece of technology that I think everybody should know is that to give the screen reader the notice that you need to start reading here, you actually set the focus of the element in the DOM. And there's a couple of things here.

We found that setting the tab index to minus one as an attribute really helped us out. In terms of how it treats the content that it's going to read out, there's lots of different settings that you can actually set there. We set the role attribute to group, and we found that that worked best given that we were typically dealing with a section of content on the page.

The other thing to note is that by default, it will scroll the content to the place where you're focusing, and that's really annoying for people who can actually see the page. So we just swallow up that next scroll event that happens, and then we focus the element.

Eventually, we want to give everybody a bit more fine-grained control on how you read things out. So instead of necessarily using the liquid fire stuff with the outlets, we could potentially just have a component that you use, like a block helper, which will detect any changes inside there.

And that would involve actually hijacking some of the stream stuff, which happens under the hood with Glimmer. So it's super experimental at this point. But we're lucky to have a lot of super smart people working on this and trying to get the word out. So yeah, thank you very much,

and start using the add-on.