 Good afternoon everybody. Can everybody hear me okay? Wonderful. Thanks for coming and I hope that you're enjoying DrupalCon. Today's session that I'm presenting is about JavaScript and accessibility. The thesis that I'm presenting is that we shouldn't blame JavaScript as a language for problems with accessibility and although I think that more and more as developers and as a community we are learning this In principle, I think that there are still a great number of developers whether I see it in forums or through Twitter or through Conversations with some of our customers some of their teams Where this is really something that people don't don't quite yet have internalized that they do think that JavaScript itself is an impediment to accessibility If if you weren't coming for JavaScript and accessibility, this is a good opportunity to leave So who am I my name is Everett zoo felt I've been part of the Drupal community for I want to say just about nine years now Spent a great deal of time contributing to the accessibility improvements in Drupal 7 core Somewhat less time contributing to Drupal 8 although nearer to the beginning of the Drupal 8 life cycle I was contributing more actively Formerly I have been an invited expert to the W3C where I participated in the accessibility task force That at that point in time was reviewing HTML 5 as a specification to ensure that it had everything needed to be to support the goals of Accessibility So what are we gonna cover today? There we go. Just getting to my list. Oh also for anybody who who doesn't know I'm completely blind I've got a one-ear button here so I can read my notes going to try not to let that distract me too much My colleague Yoshi here is driving the slides for me up on the screen. So Just to give you that context. So what are we gonna cover today? Number one Imagine if maybe just talk through really quickly a couple of scenarios around, you know What are some of the barriers that persons with disabilities do face when they're interacting on the web? We're gonna cover quickly a few myths about accessibility I think there's a lot of low-hanging fruit that we can address that will help people to understand some some misbeliefs that people may have We'll talk about a couple of truths about accessibility some facts that just maybe help to Support the reason why we might be looking at this in the first place Then we're gonna move into this is the front-end track So we're really not going to talk about code. I'm not gonna do coding examples in this session We're gonna really talk more from the conceptual and the design and and the user experience point of view around this problem And so we're gonna start by doing a little bit of a refresher on affordances if there are any designers in the room This is probably table stakes for you Maybe for some of the developers and others in the room. This is this is information you'll be learning for the first time and Then we're gonna Jump into JavaScript's role on the web Maybe that's new to some people here. I would imagine most people here understand fundamentally the use of JavaScript on the web We're going to talk about HTML We're gonna talk about the document object model and we're gonna talk about the accessibility API and how those all relate to one another We're gonna talk about divs and meaning and and why really the major challenge that we have when we're programming interactive user interfaces for the web is adding meaning We'll talk about transitions and single page page apps. I think this week I've heard the words headless decoupled and API first More in a three-day period of time than I've ever heard them used in my life Which I think is really good for our community But it does pose some challenges around accessibility as we start to push user experience more and more to the client side We'll talk a little bit more about complex UI components I'll give you some examples of where I think some organizations have done good jobs at this and Where I've seen some others do jobs where there's some improvement And then we'll wrap up by talking about what we can do next together as a community in order to Progress around the area of JavaScript accessibility So imagine if I've got a few scenarios up there on the screen But imagine if you're you're out there somebody you one of your friends or colleagues is that oh you should really try this hot new Thing it's called Twitter Let's you should go get signed up and you go to the site you get excited. You want to get start networking with people And you find out that just however you try there's no way for you to be able to sign up for the service Imagine if maybe in a different scenario. You're you're trying to find something a book online or maybe a HDMI adapter for your MacBook You spend time browsing you find the best price you find the store you want to buy it from online You add it to your cart and you you've invested some time and energy here And you find that there's just no matter what you do It's impossible for you to check out of that store Imagine if you log into an app for your job. Maybe that's an HR related app Maybe it's a travel booking related app. This is maybe it's a project scheduling and planning app It's something that's really essential to your job function in the organization And and all you see is button button button and you just can't figure out how to interact with them What any of them do or how to really use the app at all? Imagine if you tried to book a hotel room This is by the way one of the examples later on and it's impossible for you to select a date So if you want to check in tomorrow, which is the default date, that's fine But if you want to check in any day in the future, it's impossible for you to change the date in the date selector These are the types of experiences that Persons with disabilities often run into when they're interacting on the web. So they're frustrating. They're disempowering They're not inclusive. We've used that word I I think there's been a number of times in the last couple of days. I've heard the words diversity and inclusion used these are the types of experience that Work against diversity and work against inclusion in our community and in the communities For which we're using Drupal to build it to build digital experiences What are some of the myths then that we can maybe low-hanging fruit that we can quickly Dispel people with disabilities don't use my web application One interesting example of this years ago somebody said that they built a small gallery site to sell local artists paintings and sculptures online and I had suggested I took a peek at it I'm like, oh well if you're blind screen reader user you couldn't possibly use that and they said yeah But why would blind people ever buy artwork? I Think so okay, that's interesting But probably good good rule of thumb to assume that Anybody in the world if we're really trying to support inclusion and diversity Anybody in the world with any set of you know ability or disability likely going to want to interact with the web application you're building Another myth screen reader users disable JavaScript That I think that's the one that's been kicking around for a long time the reality is you know in in the most recent variant non scientific survey No screen reader users are no more likely to have JavaScript disabled than anybody else on the web Accessibility will interfere with user experience and designers don't like it. This is a very common one that I've heard I'm gonna go out on the ledge here and say that Accessibility in principle does not interfere with great design Accessibility could interfere with bad design, but I think we shouldn't really care about that Accessibility does not interfere with great design if great design is about understanding the user's goals and creating a Wonderful way for them to achieve their goals with ease and delight Accessibility by nature writes by its very by its very definition cannot possibly interfere with great design our web Application is accessible Subtext, but we've actually never tested that so you know we're just saying it I had an experience this morning with an airline that if you looked at my Twitter feed you could tell which one But I won't say it loud where it's completely inaccessible for me to check in for my flight They probably believe that that's not a problem. They probably had the development team who Did their very best to implement an accessible interface? I tested it in two browser three browsers and two operating systems and I could not check in for my flight I had to get a colleague to check me in Nobody in my industry has been taken to court that you know I'm not really as familiar with the European legal landscape, but certainly in North America It's becoming more and more rare that you'd be able to say that from from retail apparel to grocery store chains to big box stores to small mom-and-pop shops the the litigious Landscape is expanding at least in North America where it's it's harder to identify an industry where there have not been legal cases Put forward and in many cases either settled or won by persons with disabilities So why did this happen? Why did we have so many of these these myths and and untruths that floated around about accessibility? Because we've been working on this for years I think we've got a quote up here. It's one of the success criteria from WCAG But it's from WCAG 1.0 anybody that's been familiar with accessibility in the last decade or so Knows that we're working on 2.0 now and have been for quite some time And sure that pages are useful when scripts applets or other programmatic objects are turned off So I mean right there the web standards community We kind of did it to ourselves though I think at the time it was necessary because of the the state and the evolution of browsers and assistive technology way back in 1998 It wasn't possible for persons with certain types of assistive technology to meaningfully interact with a web application when JavaScript was running running and so in order to ensure that The web was accessible to all there was a rule that said you had to make sure your application was Accessible even if scripts weren't running in the browser There's a lot of good reasons depending on your application and your contingency or your constituency that's using your application to maybe look at supporting Your application functioning without JavaScript running Assistive technology in my opinion is not one of those. So although this was a really good rule in 1998 In 2017, I don't really think there's a lot of merit to tell the web application development community That you're not allowed to you build applications that rely on JavaScript So what are some things that we do know for sure about accessibility number one? It's a human right many countries have ratified the the UN's charter on the rights of persons with disabilities So right there we've got it as a right About 15% of the world's population lives with some form of disability not all of those would impact your ability to interact on the web and to be honest most Most disproportionately skewed toward developing nations still I think it's a significant number and even in In parts of the world whether it's Europe or North America or others where where we are maybe making an assumption true or false That the majority of our web traffic and users are coming from there's still a great a great proportion of people who are living with disabilities Accessibility I'm gonna try to drive this one home. It does not interfere with good design Accessibility is essential for good design And and if you're a designer here and you think that I'm wrong about that I'd be happy to have a conversation with you about that afterward Making a web application accessible is easy to start It doesn't mean you're going to do it perfectly. It doesn't mean that you're gonna remove all of the barriers But it's really easy to start doing. I think there was a great keynote this morning where You know part of what I saw as the takeaway from that was you have to start somewhere and you can't let your fear Or your lack of understanding impede you from taking the first step The reality is based on a highly scientific Twitter poll conducted by splashing magazine That less than 75% of developers know more than the basics about JavaScript or web application accessibility So if you're sitting here today, and you're thinking to yourself, I probably have a basic understanding then you're in the minority you you're already at the top of the list because more than More than 75% of developers basically say yeah, I don't really get where to start at all so on a pause here and and and really Talk about why I want to bring the design angle into this Web app web applications are designed holistically We don't build them if we don't know what we're trying to build And we don't really understand what we're trying to build until we understand who the users are Talking about accessibility from any angle really means that we understand that there's human beings those human beings are interacting in many cases with the applications we build through Modalities or experiences that are not what the majority they either then maybe they can't see the screen Maybe they can't use a pointing device But they're interacting with the application in a way that is outside of the norm We need to understand from a design perspective design is everything in That's hot design is everything inside of the browser if we don't have design If we haven't created an interaction model and if we haven't created a visual interface design We really don't have any work that we can do as front-end developers And so I think that is really important for us to understand together what it means from a design patterns perspective To create a great experience Because that's where we're going to find where the gaps are for people that are using modalities that are that are Uncommon or outside of the norm So what are affordances? There's a quote up there from from smashing magazine. I stole something else from them, but the reality is in life outside of the web outside of user interface Chairs have weight. They have dimensions. They have size. They have mass But on the screen, it's really hard to infer What types of items I can interact with what's a button? What's sitting on top of something else? What items are grouped together and which items are apart? What items can I interact with right now that I might not be interact able to interact with later? And in the physical world we've oh just over time Objects have these properties that we've come to understand through, you know Tens of thousands or millions of years of building heuristics how to interact with them But the web and and digital interfaces have been along around for so much less time That you know, there's a whole science around understanding how to make those items convey what they are and how to interact with them and The most common way to do this because the most common modality for interacting with a digital interface Is visual then a lot of the affordances or you know almost all of the affordances that are commonly used have to do with Modifying or adding visual attributes to elements that we have on the screen What are some of the important ones? There's lots of category of affordance, but I've pulled out a couple that I think are worth mentioning There's an explicit affordance. So that might just be a link that says click here That's pretty straightforward. Even if it doesn't look like what I think a link might look like If it says click here, I'm pretty likely to try clicking there to see what happens a Pattern so an example here is if we have a word or phrase with a downward arrow We've come to understand that if that that means that I can click on that and it's gonna expand and probably I can click on it Again, it's gonna collapse Hidden hidden affordances these ones get into a tricky area for users of some assistive technology These are items where not until I've interacted with it. Does it do something? Negative affordances. This is another really common category. This is where we we may be Disable the submit button on the form and that makes it look a little bit gray And we know that we can't click it We just we've learned over the last several decades of interacting with digital interfaces that when that button looks like it's all Grayed out. We even have a term for it when that button's grayed out I know that I need to do something else before it's going to activate and I'm going to be able to interact with it But imagine for some of these items, you know, maybe this last one in particular How do you tell the buttons grayed out if you can't see the button? So what's Javascript's role on the web? Javascript lets you interact in the browser Create experiences that are not just static. It allows you to modify and manipulate What's in the DOM and for those who don't have a lot of experience with DOM? That's a new word. Maybe you're maybe you're a little bit newer to Javascript in front-end development We'll talk about that in a minute, but Javascript lets you build dynamic experiences in the browser that don't rely solely on a round Trip to reload another page of content So there's these these three items and they they relate to each other There's HTML and I I would imagine that all of us know what that is There's the document object model and maybe maybe there's some people here who haven't had to work with that yet Or maybe to a lesser extent and then there's the accessibility API and I would I would venture that probably the Majority of people here today Maybe have heard tell of it, but we probably don't have a lot of understanding or experience of what it does and how it impacts people HTML that's straightforward. I'm not going to read a definition HTML is that's the markup you write that's what goes into your TPL files or your twig files When you're working with Drupal HTML is the the code that gets rendered on the server and pushed out to the browser The document object model that's what happens in browsers Chrome or Firefox any any browser really takes the HTML and one of the first things it does after the document's been loaded is parse out the HTML using a parser and Represent all of the objects that you've created all those elements with all of the little angley brackets Represents those elements in a big tree with interconnected nodes And it's JavaScript that's then able to interact with those nodes manipulate them add them remove them clone them Change the attributes of them What's the accessibility API then and this is something that people are probably less familiar with Built on top of or as an extension to the document object model Each operating system platform has essentially a native accessibility API This is what the native apps use to convey to the operating system the role and the state and the properties of UI Components, so maybe if we go back to our form example and we have a button You know the role is a button and every operating system has a way of conveying to assistive technology that there's a button in The in the user interface Maybe the state of that property like we were talking about earlier is disabled So you know in you can either have that button be an enabled button or disabled button but there's a really common vocabulary that That the that assistive technology and the accessibility API is on the different operating system platforms Know how to speak to each other in so it's robust And properties might be something like the name so click me or submit or go or please don't name a button go But it's a role a state and a collection of properties a collection of states and it's a common language It's not unfortunately common across operating system platforms But it is common within a platform and that's what allows assistive technology vendors to be able to develop technologies that know how to interface with your website and My native app and somebody else's native app Because at the end of the day all of those User interface components with their roles in their states and their properties are being abstracted out to a single set of terminology and vocabulary So when browsers have loaded and parse the HTML into the DOM They also take that DOM and they parse it out into the accessibility tree but we have a problem and I have contributed toward it and I would imagine that anybody in this room who's ever built anything on The client side has contributed toward it Which is we want to create an experience? We we don't have the tools in the HTML toolbox buttons are easy links or either buttons are easy But sometimes we still choose not to use the button element links are easy You start to get down into drop-down lists and autocomplete and date pickers and What we end up having in our markup typically and then that gets reflected in the DOM is just a C of divs and a C of spans div div div span span span and There's no meaning at all. None of those divs say to the accessibility API. I'm a date picker And none of the spans say to the accessibility API. This is an autocomplete field And hey it once you start typing in here a list is going to pop up with some options that you can choose between In HTML, we didn't really have for the longest time and with many user interface components We still don't have in HTML the ability to denote What role and the state and the properties of these more complex user interface components? And that's where we run into this problem We need to find a way to add meaning to all of those meaningless spans and meaningless divs So what allows us to do that? As HTML is a little bit complicated and I learned a lot of things being part of the working group and One of them is 400 people can't really make a collective decision very well But another one was HTML 5 isn't just the spec that we think it is so HTML 5 is a specification. It's all of the markup the tags and the properties and the attributes But there's a large collection of documents that makes up the HTML Specification that's not just about the markup and one of those documents that's part of HTML is the the why aria Specification and that stands for the web accessibility initiative accessible rich internet applications and that's a recommendation and Really what it is is a collection of states and properties and roles that don't exist yet I say yet. Maybe maybe we'll never get there, but they don't exist yet in HTML But we can tack them on to our dibs and our spans to provide additional meaning and this isn't new This has been around for a while and adoption grows over the course of time But these are roles and states and properties that we can add to our dibs and add to our spans to Expand the type of vocabulary that we have to be able to talk about Interactive user interface components with with with words and and roles and states that don't exist in HTML itself And when we do that when we start to use some of these attributes and roles from why are you I mean I'm not quite sure why you would need to But maybe you really want your button to be a span element in HTML for for whatever reason wherever and however You're using it. Maybe the styling you need to apply to it just it's it's Significantly easier if you're starting from a span than if you're starting with a button And that's not great, but that's okay because if we remember back to what I said earlier It needs to be easy to start and you don't have to be perfect at this So for some reason you need to use a span Then at the very least you need to be able to make sure that When the browser parses your HTML into the DOM and when that DOM gets translated into the accessibility API That we're saying to the accessibility API. I know this was a span, but really it's a button and so from the why are you a specification you can use role equals button and that overrides the Meaninglessness of a span and conveys to assistive technology that it's a button That's a really simple example because for the very most part you should be using the button element But when we get into more complex user interface components like tree grids It becomes really important that we are able to add on that additional information a More recent evolution that really has no implementation in any browser at the moment except for I believe Chrome canary is Something called the accessibility object model, so we have the document object model And now emerging as a specification and also in in actual implementation through Chrome canary is the accessibility object model and unlike The use of why are you where we have to stick all these roles and properties and attributes onto our dibs And they get parsed Directly by the browser, but after that we really don't have much control over what happens In the accessibility object model, which is just an API inside of the browser You're able to interact with those accessible nodes directly So you're able to call the accessible node that's part of the DOM element that you want to manipulate And you're able to change the role and change its states and change its properties directly There's a really great article. I think I retweeted it about in two days ago it was written by a Wonderful woman out of the UK who's a great champion for accessibility and if you go back to my Twitter feed You'll probably see it a few days back there and it's a wonderful explanation along with a demo of How to start playing around with the accessibility object model in Chrome There's another thing that happens As we start to push the user interface to the browser and again We've been talking we being the community has been talking about a lot of that a lot this week and and really over the last Few Drupal cons this conversation around headless API first and client-side frameworks and React just got released a couple days ago under an MIT license and now maybe You know some people who were less inclined to use react start to think hey, maybe that's something I could start to look around at The reality is is we're starting to build applications using patterns that maybe for folks in the Drupal community We hadn't looked at as much previously And so maybe we're looking more at single-page applications And maybe we're looking more at applications that have transitions between content There's been some really great work done by you know I'd sell them call out organizations for really great work and Certainly Expedia's website and I don't know if it's the same one here in Europe that we see in Canada But the Canadian Expedia Expedia website has done some really great work Around making these transitions accessible So when we go back to talk about affordances if you think about the experience of let's say booking a flight You put in your you know, you're leaving from Toronto, and I'm going to Vienna and I 25th of September to the 29th of September, and then it takes you to a page with about 50 different flight options But luckily there's some filters at the top of that page and you can start narrowing down while I only want direct flights or I only want flights that leave after 6 p.m.. And When Visually and this kind of gets back to some of those affordances we were talking about before When you start to interact with those filters on most most sites, especially Especially travel sites I've found You're not doing a full trip back to the browser. We have this in views, too, right with Ajax We we don't need to reload the page using views and Drupal and Ajax We can just update the search results or update the filtered results without needing to reload the page And often when we implement that from a user experience perspective because there is some delay between when we click the filter and When the results are updated we use a bit of a visual affordance. Maybe we add an opacity Maybe we add a spinner of some sort. Maybe we add a little Humorous message to the screen, but we do something to let the user know. Yes We saw that you've interacted with the application The update's not going to be immediate. Don't interact with these results. They're about to change. They're gonna change in a second And we normally well not normally we if we put that in place. It's always visual It always uses color or shading opacity or a spinner or a message popping up on the screen maybe sometimes a modal dialogue if If you want to go that direction Pops up on the screen to let you know don't interact with this right now From a from the perspective of somebody who's blind and uses a screen reader and doesn't have the visual modality to interact with the screen though You never really know what's going on. You kind of get used to a site I booked most of my flights through Expedia so you go there and you kind of get used to it. You learn the patterns But really good user experience users shouldn't have to be learning the patterns And they shouldn't have to be learning the patterns from one website to the next website to the next website to the next That's bad user experience. So what Expedia has done, which I think is really great and I'm gonna read this out for you the kind of the way it would read to me if I was to do a search for a flight So I do my search for a flight And my screen reader says getting flight information Departure results now sorted by price lowest and then that's I you know because I'm lazy I do not want to connect So I tick the box that says direct flights only and Then my screen reader reads out loud filtering for stops Results now filtered So this is doing the same thing that we're accomplishing with a visual affordance But Expedia is achieving the same result and it's doing it through an audio channel There's a another app. I'm not sure if anybody's familiar with the headspace app I'm actually not sure if their native app does this but their web experience if you go into headspace and log in on the web They do the same thing as you're moving through different sections of the app The assistive technology the screen reader is Reading some of these things out loud to you when you click on a new tab when you when you click on something it starts to filter It reads these out loud and Several years back we started to do some of the same things in in Drupal 8. I remember really specifically The the system tray or the tool tray when you dock it to the top or you dock it to the side We'll actually read out loud to assistive technology what's happened how how the how the user interface has changed and I think there's even an API that we have in there Which I'm not going to remember the name of but in the JavaScript API's that are that are part of Drupal you can actually push text messages and Trust that they're going to get read out loud to screen reader users. You don't have to understand how it works It's an abstraction. You don't have to go read this why are you spec and understand all the deviations and differences between browsers You can just call a function pass in your string and trust that it's going to get read out loud So how does that work? Why is all that happening behind the scenes if if you don't just want to trust that it's going to get that It's going to happen or maybe you're building a decoupled application or a single-page app And you don't have access to the to the API in Drupal that does all this hard work for you How does it work? It uses why are you and it uses something in the spec that's called a live region and the live region is really simple It's a node in your DOM Actually at a Drupal conference. I try not to say the word node Because there's a lot of ambiguity. It's an element. We'll say in the DOM That you've given a specific role and once you give it that role assistive technology knows To read new information that gets added to it Typically the pattern is to stick this node at the this DOM element at the end of the DOM You just kind of shove it at the very end is the last item and Then as you want to push these messages to the user you add new elements into that one and Trust that the assistive technology is going to read it out loud There's some roles and states and sorry there's some states and properties for this There's some states about how much of the information does it read does it only read new items? Does it read items that get removed? You know how polite is it the word polite is actually used in there. Is it going to interrupt what's being read immediately? Is it going to maybe wait till the end of what's currently being read to announce itself? And you can read about all those details in the spec But suffice it to say you don't have to learn how to do this you don't have to start working with web audio API is in order to start get your web application to start speaking you can just Simply push some text into a part of the DOM that's been marked up with this live region and Assistive technology will take it from there and the browser plus assistive technology will take it from there and and read the information out loud So that starts to talk about some complex user interaction things that maybe we haven't done a lot of in the past And I want to maybe look at a few different interactions that just as I was thinking about this talk I was looking at a few different applications I use and sites that I go to and jotted down a couple of notes about what I thought worked Fairly well and what I thought worked not quite as well I gave this presentation about a month ago at Drupal North in Ottawa And what I'd really love to be able to do is kind of show you what the experience or I guess show is probably the wrong word Let you hear what the experience is like? What I found when I tried to do that the last time is that when we're in these conference rooms There's a lot of reverb if you're not accustomed to listening to a screen reader Even if I slow it down it's really hard for you to understand what's being said and then if It really that's just generally speaking even if you were sitting down here beside me And then once we add the reverb of the conference room It becomes near impossible for you to understand what's being said I can barely understand what's being said when it's piped through the speakers Though what I will do is I'll talk through some of these examples and I've got about 20 minutes after this session before I need to do something else So if anybody wants me to kind of show them one-on-one or in a small group afterward I'd be happy to kind of unplug my headphones and slow down my screen reader so that you can really get a sense of How these experiences are significantly different from one another Uh because we're at Drupal con vienna. I thought I'd call this one out because that normally gets people riled up The menus we've got a little bit of a flyout menu thing happening in the primary navigation Well, if you can use a pointing device you have a flyout menu thing happening If you're using a screen reader you have really no way to get to the flyout menus So, you know typical pattern here you hover over top of the menu item Drops down a list of children and you can click on one of those children and go to that page directly I imagine that works quite well on desktop with a pointing device But on desktop with a screen reader. It doesn't work at all. There's some tricks Advanced screen reader users know how to do some tricks where we can use some keyboard commands to reroute the mouse And hover it manually hover it over top of the parent But that's not a good user experience first of all because most screen reader users likely don't know how to do that And second of all it leaves it leaves us guessing all the time at oh, where do I have to try to virtually hover the mouse now? It goes back to affordances Nothing indicates to us that we should be trying to hover our mouse over top of that So, you know, we would just be guessing all the way through your application that that's what needs to be done Contrary to that mass.gov This is a site that I've been looking at for a few years now and Honestly, I think that there's probably some tweaks they could do to the the exact execution But strategically they've really nailed how their menu system works their their flyout menus on that website It works. Well, you can navigate it with a keyboard It speaks really well to screen reader users You can navigate across the top level menu items and then optionally Expand down and drill into the the sub menu items if you want to I think this site is a really good example of and you know, we've been doing flyout menus For a very long time in the web community and I will say that for something that is relatively simple to get right It is rarely It's rarely done well from an accessibility perspective It's actually, you know, although it's easy to do right once you understand what needs to be done When you just start to think about it and brainstorm about it on your on your own It really isn't an easy problem to solve But so I don't want to make light of it If if you've implemented a flyout menu and it's not accessible You're not a bad person You're just They're actually hard to do unless you have a really good pattern to follow And I think that made with a couple of small Exceptions the mass.gov pattern is one of the best that I've seen In order to be a starting place for a pattern to follow Hotels.com I book a lot of my hotel rooms through hotels.com because I like to get the the 11th night free When you start to search for a location this happens a lot on the web and we've talked about auto complete before You know, if I want to start to search for vni type in vi en You know, ideally at some point there's going to be some notification or indication Visually, it's simple. You see a list drop down of possible options So this site's hotels.com is good and from an accessibility perspective, they're Fairly reasonably accessible What I will say though is that this auto complete it never indicates to you that anything's happening This kind of goes back to what I was saying earlier about patterns and and from an accessibility perspective I've had to learn how to interact with the hotels.com site But I shouldn't have to do that. I I should be able to interact with it The same as I interact with any auto complete or suggestion drop down So what happens on hotels.com when I type in vi en is From a from a textual or audio affordance perspective absolutely nothing So there's a visual affordance and obviously there's a little indicator or the the drop down automatically appears But I have no idea it's there. I've come I've come to understand when I might be typing in a box that's got a drop down So I type in a few letters wait about a second and then press the down arrow to see if anything happens And they really have done a good job at making that part work So I can press the down arrow I can navigate through the list and I can select an option But going back to those affordances we were talking about earlier If I didn't know to guess at doing that I'd never know that that really useful feature existed Compare that with Expedia And I got that ca here, but I assume it's probably fairly similar on any of their regional sites On Expedia when you start to type in when I'm looking for a flight and I start to type in vi e It will actually come up and say, you know 10 suggestions So that's that that's a little bit of an audio or a textual affordance it it tells me hey ever You've started typing vi en There are 10 suggestions available for you And then I'm like, oh great now I know to press the down arrow or if I type in vi e and it says 18 suggestions I'm like, I don't want to look through a list of 18 So then I hit the letter n and oh now there's only 10 suggestions If I hit the letter n again, maybe there's only two suggestions And it announces that out loud using that live region concept And that really from a user experience perspective is a drastically improved user experience Aeroplan this is probably something that's only familiar to I would imagine Canadians I'm not sure if aeroplan exists outside of Canada. It's a loyalty program really tightly associated with air Canada When I try to search for a hotel when I want to spend my points on a hotel When I go to aeroplan's website the date picker field is a disabled text box I can see the date in it, but when I interact with that text box, I can't actually type anything the field's disabled And there's really nowhere on the screen like I have searched and searched and searched only the other day when I was Preparing this presentation did I'm like that's it. I'm going to interact with the text box I'm going to move my little virtual mouse around the screen and click in on click on the text box And then I'm going to read from the very top of the screen to the very bottom of the screen to see Where in the DOM somebody thought they might inject the calendar pop up Which I I have to imagine that when I click on this thing There's there's no other pattern out there when I click on this thing it has to pop up a calendar So I just started reading from the top and in this weird location nowhere near the date text box But also not in that common very bottom of the of the DOM That is some weird location nearest to the top of the page I found a calendar it was a grid it didn't use a table So it was hard to interact with but I did finally find so again This is an example of having to really teach yourself for every single application you interact with Oh look, I need to type in another date. How am I going to do that this time? Is it going to be easy? Is it going to be hard? Is it going to be? Very hard. Is it going to be impossible? And I contrast that with Hilton Hilton's date picker Which is really easy to use Hilton's date picker Probably one of the best and I think I haven't I didn't dig into it Because this isn't really a coding conversation But I suspect they're using a library because I've seen the same pattern elsewhere When you with a screen reader or a keyboard start to interact with that you can navigate with arrow keys It announces everything out loud you can move between days weeks months It's a it's a really lovely experience and you know compared to the aeroplane experience where for Like a year I couldn't find the calendar in the first place and once I found it it was hard to use This is a delight to interact with I've put at the very bottom of the list here volunteers We won't do that now But if because public shaming isn't very nice But if you'd like private shaming or small group shaming afterward Feel free to come up to me again We've got about 15 or 20 minutes after the presentation and I'd be happy to Shame you privately for you for the for the poor accessibility of your application Also, if your application is really accessible, I'll I'll tweet about it. Oh good work. I'll give you a little gold star So there's something in it for you The real big takeaway that I want to I want everybody to leave here with is javascript is not to blame Javascript is a language. It's a language. It lets us it's got syntax. It lets us control the DOM control experiences in the browser, but as as you've heard whether it's Expedia or Hilton Or the others that I've referenced here You can build really accessible and really great user experiences In the browser using javascript javascript is not a problem If we look back to the beginning way back in 1998 Absolutely, it was a problem guaranteed. It was a problem And I don't want angry tweets. I understand that client side applications have their downsides We live in a world of trade-offs Whether it's slow internet connection, whether it's People with really old technologies There's lots of reasons why you might not want to build an application that requires javascript But that's not the purpose of this conversation This conversation is to say that if you've already done the trade-off analysis and decided that yes You are going to build an application that requires javascript That the fact that you're using javascript is not Impeding you from being able to build a truly accessible and great user experience You're going to have to put work in it doesn't come for free. It's not a zero effort endeavor But the fact that you're using javascript on its own or requiring the use of javascript Isn't a barrier. It shouldn't be seen as an obstacle So what do you do next? There's lots of component libraries And toolkits and frameworks where there's people working you know Drupal's not the only open source project I've heard And there's people working on accessibility. We've got people working on accessibility in Drupal We've got people working on accessibility in angular We've got people working on accessibility in bootstrap People working on accessibility and react There's there's communities built up around these frameworks and there's there's groups within those communities That are trying to make them more accessible And they're not perfect. We are not perfect in the Drupal community with our accessibility And none of these other communities I imagine are they're not perfect either But we don't need to aim for perfect. We need to aim for doing better than we're doing right now Always looking ahead and and whether we're looking ahead from a layout initiative in core Or we're looking ahead from an api first initiative or we're looking ahead from an accessibility initiative Really what we're trying to do is set a set a goal for ourselves and and always do be doing better than we are now Um, that's really all that's really all I wanted to share with you today. I think we have a little bit of time For questions before we go into questions number. I want to cover a couple of key things sprints. There are sprints tomorrow There's a slide here. You've probably seen this slide during every single session. So Look at the sprints if you're going to be here. You probably already know if you're going to a sprint I don't know if there's an accessibility sprint. Uh, that I'm not here tomorrow I have to leave at 6 30 in the morning But if there is an accessibility sprint go and learn Learn together really going back to the keynote this morning You know step one if you know nothing or you feel like you have nothing to contribute great Just go and sit beside somebody else and learn from them And then next time you'll be able to do a little bit and then you'll find out that a few times later You're able to teach the person who sits down at the table and they don't know anything Or they feel like they don't know anything or where to start Uh feedback we've got this feedback information up here I'd appreciate if you give feedback on the session and I'm sure the organizers would appreciate if you give Feedback about the about the conference in general Um, so I'll take the time now if there's any questions. I'll open it up to questions Thanks for that presentation I'd like to ask do you think that? Something like chrome vox gives relevant Relevant results for a developer Or should one just Use some other program or skip that phase and go to directly to really use us Um, yeah, that's a good question. I think that any tool gives you relevant feedback There's lots of tools out there. I think that the the question is Are you going to use just one tool? Are you going to do more of a 360 review? So I really want to drive home the point that anything that you're doing more than nothing is better than nothing I really think uh, I I published an article earlier in august on on our company website And I think in that article I suggest Find a couple of people that maybe interact with with your Application in a in a different way than than the norm. Maybe they're a screen reader user Maybe they don't use a pointing device Take them out for a coffee or take them out for lunch and just ask them To tell you what it's like for them to use the web Step one, I really think is building empathy And then maybe pay them 50 or 100 dollars and sit down with them and ask them to show you how they use your application The best way for you to learn where the barriers are in your application Is going to be to have somebody who faces accessibility challenges on a daily basis point them out to you But if you can't do that for some reason if that's not really going to work Use some of the automated tools and they're going to find for you some of the low-hanging fruit Hello, I would like to know what is a 360 review and what is the what are the criteria for a 360 review? Sure. Well, I just made that term up 16 seconds ago, but I'll I'll try to give you my thoughts I think starting with automated tools Having an expert review so having somebody who is an expert in web application accessibility come in and give their perspective And then real users of your application who have disabilities and use assistive technology So look at it from the from the technical tool standpoint Look at it from the expert analysis standpoint Look at it from the user experience standpoint and really it's not that different from any design review You know, we look at we do heuristic analysis of design We take do we take best practices and apply them we build design hypotheses using our experience And we apply it But at the end of the day until you get your design and your interaction patterns in front of real users of your application And ask them to complete tasks and observe how easy or difficult that is for them You're not you're only working on hypotheses Any other questions? Great. Well, thank you very much for joining today And if you do want to be privately or small group shamed or if you have questions for me feel free to come up after