 So yeah, I'm Ben, my Twitter GitHub handle is binhumz. I've got the slides for tonight on my website. So if you want to click on links, follow along, whatever. There's a lot of links today and if you wanna follow up, they're right there. So go there. Thank you. Can you all hear me okay? So yeah, I work for a company called Zesty. We're based in Cherry Hill, San Francisco. We're like a corporate wellness company doing catering. And if you're interested in coming joining us, please come and talk to me after the show. Yeah, so as I say, I'm talking about web accessibility and what I want to cover today is how websites can be inaccessible, where you can go and learn about accessibility, you can do to find out if you're a website is accessible. And some specific stuff to Ember, where can we make EmberJS more accessible. I'm not gonna start talking about why you should be building accessible websites. I feel like that's pretty obvious and yeah, I don't know. I don't wanna guilt-trip anybody into anything. So first of all, how can websites be inaccessible? The first one that a lot of people think of is people who are visually impaired will not be able to access the content that you've put out into your website for whatever reasons. This isn't just being blind. This isn't full, not being able to see whatsoever. You can have limited vision. You can be bad at picking out colors that are really similar to each other. You might have color blindness, which is again not full monochrome black and white. It might be that you confuse two specific certain colors. And a lot of users will be working with a really small screen or a screen that's been magnified. One particular thing that we'll see a lot is when users are navigating our websites, they're quite often only looking at a small chunk of the website and not the entire thing. So we need to be careful that we're making sure that the context is not something that's absolutely required if you're zoomed in on a particular part of the website. Users might not be able to move. This is specifically making assumptions about using our website with a keyboard or with a mouse. There's other things as well, things like touch actions, for example. If we're working with mobile, that's a thing. Specifically, a really good way to work this out is if you try just using your website with just a keyboard, you'll probably find it's absolutely infuriating. Some people navigate web pages through switches, either just pressing a button when they're like, yeah, I want to hit that thing. It just scrolls through the page and they hit a switch. Or they have some kind of greater level of mobility there. You could have like a mouse that tracks your gaze as you look around the screen. So these are things to be aware of. Hearing, if you have audio content on your website and the user can't hear, obviously, they're not gonna be able to access your content. The obvious way around this is through captioning. Text comprehension is a way that your web content can be inaccessible, and this comes down to cognitive disabilities, learning disabilities, sure. But actually language is a big one here. If you're trying to look at a website, you don't understand language, fine. And this can also be part of what we'll look at is how age might be a factor in how accessible your content is. Particularly, for example, with mobility. If somebody shakes a lot, that's a way that you can be making your content inaccessible. And similarly, if somebody's really young, text comprehension can be really difficult. Environmental factors, it's not just about people being disabled. This can be particular temporary moments. I like to do a lot of language learning. And there's websites I really like using and I can't use them on the bus, for example, because they involve some kind of audible component. So I'm just like, I can't use this content whatsoever. So particular examples are if you're in low lighting, a loud area, you're not gonna be able to hear things. If you don't want to disturb the people around you. And things like if you're driving to work, I don't know how many people use websites when they're driving to work, but it came up as an example. Similarly, device limitations are gonna potentially cause accessibility problems. Mobile devices, I feel, I don't know. I hate mobile devices, personally. And I feel really old when I say that. But like smart TVs, for example, are a thing they have web browsers now, apparently. Right, there we go. So people are using all sorts of things to look at the internet, cars included, apparently. So sometimes you might be in a situation where click events are not a thing, right? It's actually touch events. And similarly, we now have specs coming through for like specifically pointers, which is relevant to VR stuff. So I don't know if people browse the internet using like an Oculus Rift or something, but that's also a point. You can't just have like click navigation. Onscreen keyboards are a total pain in the ass. They like take up so much space and they're really difficult to use. And similarly, if you're relying on text to speech, this can be a potential problem. I think like personally, I really like the idea of using like text to speech and speech recognition in mobile is like a way around the problems with like onscreen keyboards. But the other thing, if like you're working with a platform that has like really bad support or really bad tooling, this can be a problem. Compatibility problems, your HTML might suck. If you've got invalid HTML, this is like, you know, gonna be an issue here. Similarly, like if somebody's using really old browser or if there's like some kind of character encoding problem, a lot of this stuff is things that I thought were a total thing of the past, but actually things like character encoding, okay, you know, you can just say like, all right, everybody use UTF-8. But actually, for example, and we'll get onto this, a lot of devices that people use when they can't use like traditional keyboards and mice. A lot of them don't support UTF-8 for stuff like this. So one thing is that your user might actually be a robot. This is particularly applicable to SEO for a lot of people, but acceptance testing is like a big piece of this for me because I feel like there's been a lot of situations, especially using Capybara, where you can like try and get your tests passed and you're like, no, I've put this up correctly and you definitely haven't. And so being able to acceptance test your website is a good indication that it's successful because the robot can call it. So yeah, as I mentioned, people are using more like other technologies than just like your monitor, your keyboard, your mouse that you're familiar with. So it's good to have these in mind when you're building a website. Screen readers are for people that can't see so well. They'll go through the website from top to bottom, just like linearize the entire thing and just speak it to you. So this is like text-to-speech stuff. Some people use Braille keyboards and Braille displays which are really cool. I've never heard of them before I started researching this talk. And like I say, switch devices are the types of input. So I don't know if this will work, but okay, totally not working. But this is an example of like, oh, okay, so we can hear it. Yeah, so you get an idea. This is how people browse the internet when they can't see. It's really annoying. And for me, it feels like it's going lightning-paced and they can't keep up. But this is what people are used to, familiar with. Braille keyboards are so cool. So Braille is representing regular letters, numbers, as dots, and people in conjunction with having like a text-to-speech can like get these raised dots to like come up and down and read Braille of like, you know, their Android phone. So you can see these dots here, like moving up and down to show you where the cursor is. I think that's just amazing. And similar, there's also some like technology that people are coming up with to make it easier to type, like using Braille and stuff like that. I've been generally really impressed with, I'm talking about where there's a platform and how accessibility applies to that. But I've actually generally been massively impressed with how mobile supports accessibility. I've always thought that mobile would be less accessible, but it's really great. So the general theme here for like a lot of like what you can do is if you've got text content, try to provide non-text content. And similarly, if you've got non-text content, try and provide some text content. That's like general rule of thumb. So if you have text, non-text that can like, you know, non-text options that are out there, icons, images that like represent what you're trying to, like the content that you're trying to put across there, like great. You can pre-record speech for your website in like, this is actually one of the recommendations from like W3C because the current state is apparently that the text-to-speech is not good enough yet. So like they actually recommend that you record your website spoken out. Braille representations of text. And this is one thing that I saw recommended and I'm not fully aware of the nuances of why you do it, but making a video recording of your text content in sign language. So this is for sighted people. So they can read, but that was a suggestion as well. So I'm interested to like hear more about that if anybody knows. If you've got things like multimedia, images, audio, video, they're typically inaccessible. Providing text representations of these is like really good way to go. And a lot of the way you can do this is through video captioning and like captioning images through, you know, that you can provide HTML attributes for all of this stuff. And we're seeing a lot of really good stuff with AI auto captioning stuff. I tried out Microsoft as this thing. I gave it an image of me holding a cat. And it says, I think it's a woman holding a cat. She seems happy. Is that you? I think you look 54% like Josh Gillett. And it's not completely wrong. I don't know. I'm not that surly. I similarly, Facebook have rolled out this thing where admittedly it's for their adverts. So I don't really like, I'm not fully on board, but they're automatically captioning video adverts, which is great. So like web stuff specifically. We have a markup language. I think a lot of people approach, especially, you know, I don't know, some engineers really hate any kind of like style and design. Like I shouldn't have to learn CSS. But I think a lot of people use the markup language from a point of view of like visual display. And actually it provides a huge amount of structure there that helps assistive technology and like general accessibility concerns. If you compare this to like a format like PDF, which is how I've put my slides together. So not very accessible, but like HTML actually provides a huge amount of structure for people to get at the content that you're trying to put across. And one thing that the W3C specs like put across is trying to separate in your mind the idea of content structure and presentation. So with the example of like an H2 tag, for example, the actual like words that you're putting in like I don't know, new comment is the content. The structure is that it's in like this H2 tag and that it's like a heading in like the context, the rest of the document. And the presentation is that, okay, you know, maybe it's like a bit bolder, it's a bit bigger, it stands out a little bit, it's got some margin on it. So yeah, HTML has a lot of accessibility features built in. I'm not gonna go through all of them tell you like how to do this stuff. It's actually really easy to look up a good example of this and this is actually the example that I get trolled with Capybara for all the time. Like I say, I want to fill in car description with whatever. The four attribute on a label corresponds to the ID attribute on the input. It's like super simple, but putting that together means that you can have your label somewhere else on the page and your input like will be linked up to it. It'll have that context, stuff like that. There's some as well you can get trolled by. I thought that this was really great and then I found out that it's not supported by anybody. So in HTML5 they introduced these like things for describing the structure of your documents. So like header, this is a header, this is a footer, this is like some kind of section. They're not supported by browsers or by assistive technology at all. So there's like even audit software out there now that will go through your website and check that you're not doing this stuff because it will come out as a completely flat document with no structuring it whatsoever. So the suggestion is that if you're gonna use section you should like use still H1, H2, H3, H4 to determine like this is the nested content of my structure. Web accessibility, I actually really don't like like formal documents, spec documents, whatever it is. They're all super boring, but this was actually really interesting to read and it's actually quite short. There's like 14 guidelines. They have a list of checkpoints for each guideline that you can go through and just say like, does it do this, does it do this, does it do this? It tells you like what priority you should be like, how much you should care about this stuff and it gives you techniques for how to do it and tells you like what the current support is. So like if you don't own a Braille keyboard it will tell you this isn't like really supported very much by anybody. So and also there's like a little bit of arcane stuff like frames and image maps, which I'm pretty sure nobody like ever uses these days. So I'm just gonna quickly blitz through these because there's only 14 of them and we should all know these. The first is provided equivalent alternatives to auditory visual content. This is stuff like alt attributes. There's a long desk attribute you can use as well. Providing captions and an auditory track. These are all like recommendations here. Don't rely on color alone. You can like, yeah, this is to do with being like colorblind or visually impaired. If you like, if color is the thing that's like actually presenting your content, that's a big no-no. Use markup and style sheets and do so properly. So this is partly like don't use a table to like decide the structure of your entire website or even better like, you know, just make an image of the thing that you're wanting to like display and put it. I don't think anybody does that anymore but like that's part of the recommendation. Natural language uses, you can actually like specify what language your content is in. So if you've got a text to speech thing, it can like switch into Spanish mode by just saying, hey, this bit's in Spanish and like stuff like that's super important. You can also like, if you're providing an abbreviation that's not clear, you can like there's markup for providing an expansion of what that is. Creating tables that transform gracefully. They talk about transforming gracefully a lot and I don't really know what it means. But things like you can use the TH field to indicate that this is a heading. And yeah, T-head, T-body, T-foot, use them to group rows. Like it's simple stuff but it actually helps people out a lot. Ensure that pages featuring new technologies transform gracefully. This is another thing. New technology is apparently JavaScript. Yeah. Yeah. Yeah. But I guess the question is, can your website work without Starsheets? Can it work without JavaScript? And are your event handlers device independent? So this is like what I was saying about clicks and stuff like that. That's not necessarily device independent. Ensure that control of time sensitive content changes. This is stuff like don't use marquee or like blink. So yeah, I'm breaking all the rules. No flickering. You want to be able to stop pages that auto-update. If people are really slowly moving through the page and your page is changing at a million miles an hour or auto-refreshing, that's really annoying. So providing people the opportunity to pause that is great. Ensure direct accessibility of embedded user interfaces. So I don't actually have any notes about this. I think this is like, if you've got like a video. Great. Object tag. Design for device independence. Logical event handlers. So we said about that like, don't use event handlers that are terrible. Tab index is like a thing that you can say to be like, I'm navigating the page by just hitting tab. Is all your form elements appearing in a natural order? I mean, I think that's just like not being really annoying. Like even as somebody who's very able at using websites, I can hit tab and still get infuriated by things. Keyboard shortcuts are like actually massively helpful to people besides just like navigating GitHub. You can, like a lot of people, especially people using switches will define macros. So it's not just a thing of like, oh, I have to like hit tab eight times. Like they'll just like define a macro that takes them to this page and does this thing that they want to do. So like actually providing keyboard shortcuts that are sensible in your website is just massively useful again. Using interim solutions. Again, super vague sounding thing that they have loads of instructions about it. This is things like doing the right thing with your labels. So providing labels for your forms, setting them out properly. Yeah, and this is actually like, so this is for like technology that hasn't caught up. So assistive tech, sometimes if you've got like a bunch of links that are in a line together, they'll actually like read them all out as one, just like one big thing. So I don't know how much that's the case anymore because like I like to think that the stuff that like Chrome and Apple are doing here is just totally up to date, Nathan shaking his head. Maybe not. Use W3C technologies, you're part of the club now. So they say stuff like, don't use Shockwave, don't use PDF, it's really inaccessible. Use MathML and HTML and stuff like that. I don't know, I'm preaching to the choir I think. Provide content with context and orientation information. So this is stuff like the title attribute. I'm pretty sure every Ember app I've ever made just has the same title attribute for every single page. I don't know, has anybody put any effort into changing their titles? I don't like. That also applies to like, if you've got a group of options, you can use like an opt group element to like group them all together. And similarly like form content can be grouped together using field set and legend. Clear navigation mechanisms is like an obvious thing. Provide good link text. It says stuff like navigation bars are good for people, obviously I think a lot of this stuff is pretty obvious. Think about providing a site map. And a lot of screen readers for example, when you're navigating a website through a screen reader, I don't know if you've ever, if you see somebody who's a total pro at it, they're like, they're very quick at just recognizing from the start of a link or the start of a heading, like no, this content's not for me. So if it's like, this is a picture of blah, blah, blah, like that's not massively helpful. So try and put like the actual content that you're putting across like right at the beginning, like front load it. Finally ensure that documents are clear and simple. This is just the thing of just like, make sure your language is simple and clear. Don't be too complicated. What I'm not touching on here is this like slightly bigger thing, which is really cool again. This is specifically for like rich internet applications. There's a group of people putting together guidelines and whenever you see like area stuff and you're kind of like, what's all that? It's a lot of what my understanding is that it's for like saying, this like really random little component that I've made, it does this kind of thing. So that's an interesting one to read up on for sure. W3C is on GitHub, who knew? There's loads of stuff there. There's also a Slack channel. Ryan Florence I think is in it maybe, we'll see. There's a talk that Jamie White gave the London Ember Meetup I recommend. I've not been able to find a recording of it, but there are slides with lots of links. I've basically copied all of the links and content in his talk and put it in my talk. So these are all fantastic talks that you can check out. They're slightly English centric. A lot of these people are English, which I can only say is a good thing. BBC provide a lot of guidance on how to make your websites accessible. So do the UK government actually. The guys at, this is the government digital service, have a load of amazing stuff, open source stuff. I'm sure you've all seen them before, but they also have some accessibility guidelines. They're very good. On the topic of working out if your website is accessible, I think a lot of people know that you can just manually verify stuff. And there's varying degrees of effort that you can put in. One of these is just try navigating with a keyboard, like put your mouse aside. If you feel like a pro hacker, you can do everything with a keyboard, right? Screen readers actually is really easy to turn on in OSX and in your iPhone, probably Android, I don't know. Just try it out. See what that feels like, see what that navigation flow is, even if you just do it once, you'll very clearly, very quickly see this is really painful. Try disabling star sheets. Does it like, is the order of the content sensible? Text-only browsers, I wouldn't recommend using links, but see what you could do to actually just pull out the text content itself and see if that's sensible. I was very inaccessible a few years ago, well, like a long time ago, when I was trying to set up some kind of extremely custom, the next distribution, and I just couldn't use the internet, so links was my only option, and yeah. Also, just make your resolution really small, see what that looks like. Some people are using really beefed up font sizes and stuff, so this is, I guess, kind of like testing for mobile, but if you've got a responsive website, maybe that'll help. There's a bunch of accessibility tools on GitHub, this link, check it out. It's like, the most interesting stuff, I think, is audit tools, but there's jQuery stuff, there's links to all sorts of different, I don't know, check it out. One of the resources that's there is like, most of these are provided by W3C, are things that will tell you what all of the English names are and all the different keyboard codes are, so when you start mashing your keyboard and you're trying to add them, keyboard shortcuts, this will tell you what that is, so these are useful. Audit tools is a massive thing of this, so instead of going through your website and manually checking everything, you can have a tool that will just introduce it to your CI, whatever, it'll automatically go through and point out things that just don't lend well to being accessible. So you can get this as a browser extension, just run it as a one-time check or install it into your CI. A couple of examples of audit tools that are out there that are some accessibility tools provided by Google, they do lots of stuff, the Chrome team, lots of accessibility stuff there. So you can get that as a Chrome plugin, you can run it from the command line as well, so that's super helpful. Oh, I have a video, fancy. So yeah, this introduces an audit section to your browser panel, and you can just say, right, I just want to audit accessibility and it'll pull up a bunch of different warnings, different priorities. Axe is another one out there. Yeah, we'll see that, it's very popular. Tenon is a third-party one you can use as well, they have like a pretty comprehensive suite of checks, I've not tried using it myself, but yeah. There's some framework-specific ones, you'd be surprised to hear. I've not looked into them massively, except for the number one maybe. Yeah, so React and Angular all have their things. I think Ember A11-wide testing is using Axe, is that right, that's right, okay, cool. So yeah, the idea here is that you can just install this, drop this in, and it's ready with everything you're doing. I'll get onto that stuff. I guess I'll get onto it now. How can we make Ember JS accessible? So there's a lot of big gains that we can make from having this framework, having these common practices, everybody all works in the same way, so it's pretty easy to distribute stuff like this Ember A11-wide testing, which just like everybody downloads it, I hope you will download it tonight and just start putting it into your CI tools. We have like an accessibility team, so this is a team of people getting together, complimenting each other about the once-in-a-fort night. We all get very confused about different ways of speaking English. We've put together, oh, this is the team, there's some people there. There's Ember A11-wide testing, we're putting that into the domain of this group. I'm thinking about putting together like a colorblind simulator. I've played around with WebGL filters and they're kind of easy enough, but I don't know if you can just apply it to a whole web page very easily. If anybody wants to come and hack on this with me, do come up and say hello. I'm sure you could probably do it with CSS or something either, either way, I'm sure, like Eric's CSS stuff, maybe. Nope, nope. Templating the thing is a massive boon. We're seeing this come more and more into the spotlight. We held a hack day at Zesty and did a bit of work on that and we've just seen it move forward from there. Actually, this is one area that if everybody's got template linting installed, we can just start giving advice to people about how to do accessibility for their templates that are very specific handlebars advice. The other thing that I have to say is that already you've got valid HTML or your divs are gonna be closed and stuff like that just from using Ember, so that's great. Fastboot, we say about JavaScript being a super modern technology and you should try your website without it, but actually we can kind of. Fastboot should be a way of getting yourself together a nice little HTML page. Your website will be more accessible just by dropping it in, I hope. It's not like waving a magic wand, maybe it is. And similarly, I'm interested in exploring how we can look at actions. Are we being irresponsible with a click event handler? Does the native Ember input helper just do the right thing? This is something where we can look at making Ember a bit better for this stuff. Page titles as well. I looked into this having never set up a page title is actually really, really easy. There's this item and you just install it. You say, hey, look, give me a title and they even nest them with your nested roots. So it's beautiful, really easy to do. If any of you are interested in getting involved, we have a Slack channel where all the people from Ember A11Y, we're chilling out there, we're lurking. This is on the EmberJS community Slack channel. You can get to that through the EmberJS website. We're putting together a demo app. And this is mainly with the intention of providing a space for people who are developing assistive technologies to come along and just test Ember out. So we're like, we've got loads of examples of typical uses of standard EmberJS and a collection of the really common add-ons that are out there that people are using. And part of the intention here is that we should be able to really quickly spot any areas where we're not doing things as well as we could. I think one thing that I'm personally extremely excited about is in two days, this is on Thursday, there is this global accessibility awareness day. And as a community, I'm hoping we get loads of EmberJS people to muck in and take the day out to if you can convince your boss to say, right, today I'm going to work on getting accessibility together for our website or helping out with some of these community contributions. Have a look at the EmberJS blog. There's a post from today. Nathan over here, do talk to him, tell him all his spelling errors and stuff. There's a bunch of links on there for ways that you can get involved. They are offering pairing sessions, so you can just go onto the website, sign up, organize a pairing session with one of us. There's also a mailing list and stuff, so have a look at that. And there's all sorts of talks, panels, things happening. You can have a look at the global accessibility awareness day website. There's going to be a talk from Google I.O. that I'm excited about seeing. Yeah, loads of cool stuff. This is my desktop. Any questions? I do not want to see what this looks like with a screen reader. Can you imagine? Torture. That sounds good. I'm trying to get it to fill up as much as possible. It's kind of, on a small screen, it looks much better. Any questions? Two questions. The question is, what's the easiest thing that somebody could do if they have an hour to improve the accessibility of their website? I think, personally, the best thing to do besides hooking up, I mean, you could just hook up Ember A11Y testing into your CI and then you'd like reap the benefits of annoying all of your colleagues. But personally, I think just going through with a keyboard, trying to like tab through, see what everything looks like. Turn on the screen reader. Just browse through your website, try it out. It's horrible. Yes? Good question. So the question was, if you wanted to see a real like best in class experience of using a screen reader, where would you go? What would that look like? My answer is that I have no idea. But Nathan might have an idea. Facebook. Facebook? Facebook is really good apparently. Yeah. So like, yeah, go have a look at Facebook. I've heard that Facebook is actually also really good on mobile. So that's like double accolade right there. Okay, great.