 All righty. Good morning everybody. Hello. Hello. My name's Everett Zuchout. That's a little bit hot. My name's Everett Zuchout. I'm from MyPlanet. I'm the director of technology at MyPlanet. I'll just maybe wait. Is that hot for you out there? Is that just me? All right. Wonderful. All right. So my name's Everett Zuchout. I'm the director of technology at MyPlanet and I'm here to talk today about JavaScript and accessibility. Hypothesis. JavaScript is not the problem. You're going to hear that a few times through the presentation today. Before I get started though and kind of go into the agenda and the topics I want to talk about, you know, honestly I can talk a long time about this, but I want to spend a couple of minutes understanding who's here, kind of what's the makeup of the room, and as I go through my slides I can kind of tell different stories depending on how people are looking to hear. And I mean I assume there's a number of people here, so we don't need to all go do introductions, but is there in particular a couple of people who want to pop up and say, you know, here's why I came to this session. Here's what I'm looking to get into this today. Don't be afraid. I'll begin. I work at the Canadian Institute for Health Information and we're constantly striving to be as accessible as possible, but it's a bit difficult because there's well, one, there's a culture shift, and two, a lot of people kind of misunderstand what are the causes for common accessibility issues. They'll blame, for example, JavaScript. They'll blame, you know, missing alt text or whatever, but they forget that context is hugely important. There's a lot of other factors, so this is very interesting for me. Excellent. And so I'll just kind of synthesize that, which is, you know, trying to make things more accessible in an organization where maybe that is more of the constituents have disabilities and, you know, just wanting to understand what are some of the common things that are easily blamed when maybe there is really a solution. Yes. Anybody else, reasons that you're come today, things that you want to get into the session? I'm working on a content-based module for the purpose of facilitating social media interaction, and because of the nature of the type of content and, you know, how loosely it could be determined, trying to figure out what the best translation solution is, if any translation is relevant for this in certain sense. So maybe something like this offered by the solution. Excellent. Anybody else? Mike Kipper, just wanted to go over and say that I've always interested in what you have to see about accessibility, but also that the JavaScript is a particular challenge because not because it can't be done right, but because so often developers go off and just do everything with divs and spanins and forget all of the HTML that they should have learned, and we're interested to hear about the cultural changes that are necessary to get JavaScript to be done, coded breaks, and actually respects HTML semantics as opposed to, oh, we're just going to do this bulk area and ignore that, the HTML structures. Exactly. I think that's a good point. I'll synthesize that down to the understanding that it can be done right, but that very often it's not done right. You know, what are the, what are some patterns for starters that are good examples, but then what is the cultural change that needs to happen in order to get people to understand where to put the effort in order to make things go the right way? I'm David McDonald on the WCAG team, the honorary team for WCAG, and I'm looking to put the nail in the coffin of a myth about JavaScript once and for all from a great authoritative source yourself. Excellent. So, synthesize that just wanting to finally once and for all put the nail in the coffin and let's make an authoritative statement that JavaScript itself is not the problem. That sounds good. So, I'm going to get started here. So, once again, my name is Edward Zufelt. I'm the director of technology at Mono Planet. We're a software studio. We design and build digital products. A lot of the work we do is with Drupal. We do work with other tools as well. Pretty much any application we're doing with Drupal. At this point, if you're building something in Drupal, we normally use React.js on top of it, at least to some degree to build a better user experience than you might get out of the box with Drupal. The common vocabulary I think we use in the community for that is either decoupled or progressively decoupled Drupal. So, we do a lot of that work. We also do a lot of work where we're building pure JavaScript applications. Node on the back end, Angular, React, Vue.js on the front end. So, we do quite a bit of work with JavaScript within and just separate from Drupal. I guess I'll go back. In the past, I have worked on a few different things. I was the Drupal 7 accessibility maintainer a few years ago. I kind of stopped contributing in a huge way to that. But in Drupal 7, I contributed quite a bit to accessibility. In the past, I've been an invited expert to the W3C HTML working group when they were putting together HTML5 and specifically worked on the accessibility task force and contributed some opinion around the changes that would need to happen in order to ensure that as a language, HTML had all of the tools necessary in order to allow people to build accessible applications. And then for anybody who's not aware, I'm completely blind. So, I've got a headphone in here and I'm listening to my computer talk. Depending on the audio system, maybe we'll do a little bit of a demo at the end here just as kind of a little example of some. What I think I found are a few really good examples specifically from a screen reader perspective and we'll talk about kind of some different angles on accessibility, but specifically from a screen reader perspective, a few examples that are worth looking at, good patterns around complex UI components and how they can be built in an accessible way. So, a few topics that I want to touch on, so imagine if, so I think let's just talk about some scenarios that persons with disabilities might find themselves in. Myths about JavaScript, David had mentioned just a second ago that it is a myth that JavaScript is not accessible. Some of the truths about JavaScript accessibility, so I want to touch on that as well. And then really we want to get digging into some of the aspects. So, this is not going to be a really code related, if you're, there's not going to be code examples in this presentation, but really starting from the angle of design, user experience design down through into some of the tools and technologies that are available to create accessible experiences. We want to start taking a look at from the design angle, HTML, we want to talk about the DOM, obviously we want to talk about JavaScript, and then we want to dig into some examples, whether it's around live regions, date pickers, some of the more complex UI components to make work. So, I've got a few imagines up here on this slide, but I'll really just talk to some personal experience because that's something I have the ability to do. So, you know, it's hard to, if accessibility on the web doesn't affect you on a daily basis, it's really hard to understand what the impact is. Really, I think a few key experiences that I personally have had is, you know, imagine if you're on an e-commerce site, you've spent your time researching this product, you've spent your time learning about it, you've picked the product, maybe you've configured it, you've added it to your part, you're pretty invested at this point, you're going to purchase the product. And now it's impossible, you put that checkout button as many times as you want, it doesn't do anything. Nothing's happening, nothing's moving, you can't progress down the flow, and inevitably you either are going to have to phone in or kind of go back and start searching elsewhere for whether or not you're going to be able to buy the product. Other examples, you know, let's say there's an app that you need to use, maybe it's part of your job, maybe it's for booking travel, maybe it's for submitting expenses, but there's an app that you need to use as part of your job, you go to log in, logging in is fine, and now you're just in a sea of buttons that don't have any labels on them at all, you have no idea what any, you can click randomly around the app, but you really just have no idea what any of these buttons do. So these are some of the experiences, or maybe you're tapping around the app, sorry, and you just, you can hit, you can fire away on that tab a hundred times and you have no idea which one of the elements on the page have focus, and obviously in that scenario you just, you can't use the app, you're going to have to go back to your boss or go back to whoever, and the company said that you needed to be using this and say, hey listen, I, you may be invested in this and the company might be telling me I have to use it, but it's impossible, I can't do my job using this tool. I think that, I hope that gives in a sense of the magnitude of the problem. It's not, you know, I couldn't get to a specific cat video, you know, so I have to go find a different cat video instead. This is, you know, I can't purchase something from my home, I can't purchase something from my family, I can't interact in my workplace with the tools that I'm, that everybody else in the workplace is using. So the magnitude of the problem I think is significant. So myths about accessibility, particularly myths about accessibility in JavaScript, people with disabilities don't use my product or service, well they probably don't if you've done a really poor job at making the product or service accessible online, so I think that's one key myth. I'm not going to go through all of the myths up here, you know, we've, we've, our website's accessible, we know our product, we know our app is accessible, you know, we haven't tested it at all, but our developers tell us that it's accessible, that's another good myth. Especially when it comes to procuring websites, you know, you put in the RFP, needs to conform to WCAG 2.0, not a single vendor to your RFP, by the way, is likely going to reply and tell you that they can't do that. Everybody's going to reply and say, absolutely, we're going to conform to that standard. The question is, at the end of the day, did they actually conform to the standard? You know, accessibility gets in the way of design? Absolutely not. Well, let me rephrase that. Accessibility doesn't get in the way of good design. I don't know if there's any designers here who feel differently, but accessibility might get in the way of bad design, but it doesn't get in the way of actually doing design well. If the purpose of your role as a designer is to ensure a great user experience for all of the constituents of the application, then by, by definition, accessibility can't get in the way of great design. If the purpose of your role as a designer is to feel good about having created something that you think looks good, but having no real understanding of whether or not anybody else finds it to be useful or easy to use or delightful to use, then I think you should look for a different career. I put a little quote up here. Basically, let's synthesize this quote from WCAG. It says, you have to provide an alternative version of your website because people can't use JavaScript. And if you notice in the citation, this is from 1998. So I want to, I want to kind of drive this home. It was a problem at one point in time. Now, 1998, this wasn't that far after scripting languages started to emerge on the web. 1998 was a long time ago. I could see when this rule was written. And I was, you know, some people had more hair than they have today or their hair was maybe a bit of a different color. I could see this was nearly 20 years ago. It was a problem 20 years ago. The technology, whether it was screen readers or other types of assistive technology, depending on what they were, were less capable and browsers as well were less capable of creating an accessible experience when there was script running on the web. But that was 20 years ago. It's 2017 now. This isn't a problem anymore. Now, because innovation outpaces standards and standards outpace regulatory conformance and whether it's regulations or laws around accessibility, you may still find in some jurisdictions that there are regulations and laws that mandate that applications work without JavaScript or without scripting languages. That's regulatory conformance, and you might have to conform to that. That you might be under the mandate that you have to conform to those types of rules. Let's not mistake conforming to those types of rules with creating an excellent user experience for persons with disabilities. They're related, but they're not the same thing. Some of the truth about accessibility. It's a human right under the United Nations Charter on the Rights of Persons with Disabilities. 15% of the people in the world live with a disability to some extent or another. I will say that that's probably a statistic skewed more toward developing nations. In developed nations, that percentage would be on the lower end of the scale. It's still a significant number of users, constituents, customers. However you want to look at the people who interact with your application, it's still a significant number of people globally or locally who have some sort of disability who likely impacts their ability to fully engage with you, your brand, your organization, through digital channels. Really one clear truth, and I'm going to hammer this home through the whole presentation. JavaScript as a programming language is not inaccessible. I feel like I can speak with great deal of authority. I don't like appeal to authority as a logical argument, but I am completely blind. I write JavaScript. JavaScript as a language is not inaccessible. This comes from recently, actually I was really happy to see this recently. Smashing Meg did a Twitter poll, which I think is one of the most robust ways to survey an audience about what's going on in the world. 75% of the respondents to the Twitter poll essentially said that they had no better than a basic understanding of how to make complex web applications accessible. We're probably dealing with the types of persons who respond to these types of polls. Those types of persons are interested. You're not responding to a poll because you don't care about the topic. Of people who were interested enough to click on a button in Twitter, which is not a very high threshold, 75% said their level of knowledge on this topic was basically below. That really goes back to the point that Mike asked, which is this probably isn't about solving this problem on the web. It's probably less about technology at this point. It's more about taking that 75% of web application developers and giving them the tools and the encouragement they need, the support they need to do the job that's possible. I don't want to save questions for the end. I'm going to pause there to see if there's any questions. Did you mean in that last slide that 75% of developers have, 75% have less than a basic amount? Just have a basic? Yeah, that's a good question. Based on the Smash and Make poll, 75% of respondents indicated that they had a basic or less than basic understanding of how to make web applications accessible. Good question. The question was, to what extent are browsers part of the problem? Let's try to synthesize it that way. To some extent, I think is the answer. Browsers, as we all know, we're at a development conference. They all implement standards a little bit differently. They all implement standards with different amounts of timing. And it takes an investment of time and energy just trying to get your styles to work cross browser, trying to ensure that applications are accessible across browser, take some time, take some looking into. It takes building up a knowledge of which browsers have implemented which features. I'd say that as of where we are today in 2017. If you're using a modern system, if you're using an auto-updating browser, you're probably pretty good. Yes, there's glitches. Yes, there's inconsistencies. You're probably pretty good if you're using a modern browser. If you're stuck back in IE 8, 9, 10, you're not so good. It's not such a good experience. Affordances. I'll move on here. Why am I touching on affordances? There's a lot of different angles on accessibility. What I was going to do just for the sake of time, I left it out, was going to go through some personas, persons with different types of limitations, whether it's cognitive, motor function, visual. There's a lot of different people. We all interact with the web in different ways. Some people like myself use a screen reader. Other people need to use different types of pointing devices. They can't use an outside touch pad. Really when we take a look at it, when we're talking specifically about where complex user interface components are involved. I'm not talking about colored palette selection and I'm not talking about being able to have alt text on images. You've come here probably because you have a rudimentary understanding of accessibility and you'd like to know more. When it comes to building complex user interface components, the area where you're going to find the greatest amount of challenge is for keyboard-only users or persons using a screen reader. All the other things being said, yes, the color palette end when you zoom, it needs to scale properly. The real complexity of it comes down to screen readers and keyboard-only users. When we start to talk about screen reader users, and so now it's really narrowed down that category to persons who cannot interact with your web application through a visual modality, they can't see the screen. When we're talking about screen reader users, the topic of affordances is important. We've got a little quote up here. Really at the end of the day, how do you know that that button is clickable? When you look at the screen, how do you know the button is clickable? There's a visual affordance. We have agreed on some patterns, we've agreed on some best practices across the web. We make a button look like it's a button. How do you know when content is updating on a screen? Maybe you're filtering results and you've clicked a check box to filter results. How do you know content is updating on the screen? You know it's updating because we've applied a visual affordance. Maybe we've created a spinner. Maybe there's a little message, a dialogue box that's popped up. Maybe we've added some opacity to the page, but we're doing something visual to indicate to the user how or how not to interact with the web application. For persons with disabilities, particularly persons who cannot see the screen, those affordances are almost completely lost. There's a couple of important affordances. Really I think the key thing, and there's lots of different categories of affordance, but I think there's a couple of key ones. I think really negative affordance, and I'll try to show you an example of this in a little bit. I think really a negative affordance is quite honestly the one that I'm talking about specifically there, where something on the screen changes to indicate to you that activity is going on in the background. Don't interact with the application right now. Outside of that there's other affordances as well. We've got the ability to indicate a hidden affordance when I... Eric, your voice over is over top of your slide. Let's see here. Let's try. It's a great way to scoop whatever you're about to say. There we go. Let's try that. Now we've got that turned off, so hopefully the slides show up better. Hidden affordances. When you click on the date field or hover over top of it, we didn't know that was there until we clicked on it or hovered over top of it. Something indicated to me that I could take an action and something would pop up. I think there's a number of affordances, and when you start to think about the interaction on the web, if you can't see all of these visual cues, that's where we start to really roll into some pretty big problems for persons who can't see what's going on on the web. I'll just advance this slide here. JavaScript's role on the web, I think we'll pass over this. I hope that everybody here gets JavaScript as a programming language, primarily what JavaScript is used on the web to do because JavaScript is ubiquitous. JavaScript is in embedded systems, JavaScript is on the web in the web browser, JavaScript is on the web on the server, JavaScript is everywhere. It's a ubiquitous system or programming language, so on the web, however, really what's JavaScript used to do on the web JavaScript used to manipulate the DOM. I want to make sure because I know that this is kind of a front-end session and not knowing where everybody's level is at. I want to start with just a couple of basics before we talk about some of the more complex things. HTML. I have to assume that everybody in this room would really rock solid understanding of HTML. So HTML is a markup language for content, but really as it's evolved over the years and really just in the last few years specifically, we've started adding things into HTML that are much more complex. We've started adding things like date pickers. We've started adding things like sliders. We've started adding things like dialogues. We've started adding to the specification of HTML components that are less like a document and more like an application. Your blog article doesn't need a date picker, but your hotel booking app needs a date picker. So as HTML has been evolving, we've been adding to the markup language the ability to add controls that are more and more like controls that you'd find in an application. I think I've advanced there. The DOM, this gets a little bit deeper. This is one layer further down and maybe if you're more familiar on the design side and you do less coding and less writing of software, DOM is getting one more step removed from your design. The DOM is really the in-browser representation of what is going on in the HTML. So when the browser loads your page, it's going to read through the HTML. It's going to create a big object model for the document. It's going to find all the buttons and make them buttons and find all of the JavaScript and execute it. It's going to go through the whole thing and build up a big tree of elements that represents the document. And the last thing that's going to happen in modern browsers, because this exists today, is we're going to take that tree of documents and we're going to map it against an accessibility API. And that's probably one layer deeper. That's even if you're a really experienced front-end developer, you might not know that this accessibility API exists. That might be new information for you. So we've taken the HTML and the browsers parsed that into the DOM. And now we're taking the information from the DOM and we're mapping it into an accessibility API. That API is pretty specific to different platforms. So Apple has an accessibility API, there's one on Windows, there's a couple on Windows. So that API is really the same API essentially that's used if there's a native app. So if you have a native app running on OSX, if you have a DOM mapping content from a web browser over to the accessibility API, what we're really trying to do through an accessibility API, or what the platform vendors are trying to do through an accessibility API, is to create a common language, a common vocabulary, a method of representing user interfaces that is reliable and robust so that assistive technology doesn't have to program against each individual application. Is there anybody for whom the concept of accessibility API completely brand new to there where we all knew that this existed? Let's move forward. Actually, let's take care for a second. So how does the application change? So the application changes because JavaScript modifies the DOM, JavaScript modifies the DOM, and that updates the accessibility API. So I want to try here, and I don't know how successful we're going to be, I think maybe we will be with the audio system, but we're going to try here to do a couple of examples. What I want to show you is a couple of examples of applications where we're leveraging some newer tools and technologies or standards, and I think these applications have done a particularly good job at actually taking some of these complex user-indicated face components and making it accessible. So let's see here. Let's get rid of that. So I'm going to, let's start by, in a switch audio here. Just give me a second. All right. So I'm in Firefox. And let's see what we get here. So let's try this again. All right. So this link, they did not like me pasting this link back in here. So let's try again. So the question in the front row is, how is he on a Mac book? And I hear Jaws speaking. So that, I'll answer that question on the Mac built into the Mac. There's this wonderful screen reader called VoiceOver. It's delightful. It's built in. You don't spend any extra money. If you're blind, you buy a Mac, you've turned on the Mac, you can use it just like anybody else in the world. That's lovely. And there are applications, primarily web browsing, that I very much dislike using on a Mac. I enjoy the pattern of using it on Windows better than using it on the Mac. So I have a virtual machine running Windows. That's probably very common to most people here, especially if you have to do cross browser testing. Inside of Windows, I have a commercial screen reader running called Jaws. That is not free. It is not included. It does not cost zero dollars. But I have that running inside of Windows so that I can interact with Firefox on the web. So let's take a look here. So I'll show you a couple of things here. Can you hear this all right? I tried to slow this down very slow, so that you could experience this. So let me just take a look here. So where am I going? Let's go to San Francisco. So I'm going to go on one slash nine slash 2017. And I want you to listen here. You're really not loving me, Expedia. We have lost our audio altogether. Unresponsive. Isn't this lovely? It's telling it to the other boxes. Yeah, Expedia, you did such a nice job for me earlier. Let's try this one more time. What I want to show you is the great job that I thought Expedia had done here. This, but I'll switch over here to Flikes. So let's try this again. Why was he? Let's try this again. Yeah, I want you to listen. I want you to listen. So it said searching for the shortest flights, finding the best fares, results now sorted by best price lowest. So I want to say that this is nobody does this. I use websites all day long every day. Nobody does this. When you come to this page and you're looking at the page, you can tell there's no results yet. And I'm sure these messages are up on the screen where they're saying, I know we're slow. We've got to check a lot of airlines. And so we're going to put a few messages up there. We're going to let the user know what's going on. We don't have the information they're looking for yet. But for a good user experience, we're going to inform them what's happening. This never is made accessible. Nobody does this in an accessible way. I think it is really a great example on the Expedia site that they have as these things are loading. They're actually making that information as it updates accessible to somebody using a screen reader. Then they go a little bit further than that. So I'll show you the example here. We've flipped down. So I'm not going to connect. That's not an option for me. So I'm going to check this checkbox for nonstop flights. I see there's 11. So I'm going to check that checkbox. Results now filtered. So I actually know what's going on. It indicates to me because imagine if you weren't looking and you checked the checkbox. I mean, you can guess what's going to happen. You don't really know if there's a button you're going to have to hit to apply this. You really have no idea what's going on if you can't see the screen. And so I think Expedia does a particularly good job here at providing those updates live. And if we, I'm going to jump down to the bottom of the screen and you're not going to see what I'm looking at here. But if I jump down to the very, very bottom of the window. So the very last line of text that my screen reader can read says results now filtered. And what Expedia has done there is they've actually stuck a tiny little hidden div probably or span at the bottom of this DOM. That's where all the information about the application is stored. And they've marked it up in a way that makes it read information out loud to screen readers. Please don't do that to your entire page. This needs to be used sparingly. Use you use tactically. So I'm going to flip back over here to the slides for a second. Let me know if they're not showing up well. So this is why we didn't have that plugged in a second ago. So there we go. So what is this? We talked about HTML and that maps into the DOM. We talked about the DOM on every different platform that maps different into a different accessibility API. And so if you call something a button in your HTML, it's a button in the DOM and it gets mapped as a button into the accessibility API. And that works exceptionally well. Until you start calling things divs. Until there's nothing inside of HTML to represent what it is you're trying to create. But it doesn't work well at all. It doesn't work at all. So on top of HTML5 and if you ever want to have a long debate with me, I can tell you why I don't believe it ever should have been on top of. But on top of HTML5 is another standard from the W3C. It's called why aria. Aria stands for accessible rich internet applications. And aria essentially extends the semantics of HTML5 to support many new types of user components that don't exist in HTML5. One of the components, and it's really not a component, you know, it's not something you interact with. You don't click on it. It doesn't do something. One of the components is a live region. And live regions allow you to announce to assistive technology that something on the screen has changed. So Expedia there is announcing to my assistive technology using this live region approach that the flights are now filtered by or that they're now filtered by number of stops. I just flipped. Certainly. Yes. You ask an excellent question. So or the comment or question is is aria going to become redundant? Hopefully. You know, and there's a lot of opinions and reasons going back and forth. Really aria should be part of HTML. And it is. This gets complicated. And David up here can tell you far more about it than I can because he's been dealing with the wonder that is the process of creating standards for much, much longer than I have. HTML is actually a suite of standards. Yes, there's one called HTML. That talks about all of the elements and the properties. But it's actually a suite of standards within the suite of standards of HTML is the why are you recommendation? So it is it is compatible with it's under the umbrella of HTML. But you're right about the fact that it really is a full time solution to HTML. These are these are things that didn't make it into HTML. So now they're available in a separate document to be implemented alongside or on top of. I guess another another part of that though is that one reason why aria maybe won't become redundant is it's not actually just for HTML. It is a set of semantics properties and states that can be used with any markup language. So yes, you can use it for HTML, but you could also use it for SVG. So I think it kind of goes both ways. There's a lot of opinions around it. I think it would be easier if the date picker or if the you know whatever whatever the components are in aria that aren't in HTML would it be nicer if they were all in one spot? Sure it would. The fact that they both exist that they're both recommendations from the W3C and that to date browser implementers or user agent implementers have been implementing them both at the end of the day from a practical perspective that's what matters to ensure the web is accessible. I think we only have a few minutes left. I know we started late because the rooms were getting set up so I'm not quite sure what the end time is. But I'll go through one or two more points here and then I'll see if there's other questions. We're going to switch back over because I can't even understand what that's saying at this point. That's saying something. Alright complex UI components. I've listed a couple here and I don't think we have time to go through all the examples but I'm happy to sit down after the presentation and talk about any of these examples with anybody who's interested. So the one example actually I'll just flip over. There we go. We'll just stay on the last slide here. The one example menus, mega menus, expandable menus. I offered an example because it's Drupal North so I thought if I point out the DrupalCon website that would get people all wild up that's a very bad example of an accessible menu. That is, you know, it is a menu that I actually I went to the website to try to find the hotel information. Couldn't find it because the menu was inaccessible. I ended up just googling, you know, DrupalCon via a hotel. Whereas mass.gov, not sure if anybody here, you know, or in Ottawa were reasonably close, mass.gov, really great example. They've taken kind of a unique spin on their drop-down menu from an implementation standpoint but from a practical usability standpoint, really great example of a menu built with JavaScript that you can interact with with a screen reader. A couple of other things. Date Picker. Not sure who has Aeroplane here. Date Picker, if you're trying to go book a hotel with your Aeroplane points, terribly difficult to use. There's a little date field. Can't type the date in the date field, just read only. There is a calendar pop-up somewhere but you have to kind of search in all around the screen with your screen reader to try to figure out where it is you can actually pick the dates. On the flip side Hilton, any Hilton hotel that I've ever tried to book, wonderfully accessible Date Picker. When you interact with the date field on the Hilton hotel Picker, first it gives you some instructions, says, you know, press the down arrow if you just enter the calendar and press the left and right arrows to navigate. It is a wonderfully accessible Date Picker from a screen reader perspective. Another example there, Autocomplete. So Autocomplete is an exceptionally hard component to get accessible, in my opinion. We really actually, years ago, I think, did a great job at making it accessible in Drupal 7. So the Drupal SIF, you're just using the standard out-of-the-box Drupal 7 Autocomplete today. Haven't tested the Drupal 8 one in a long time, but I'm going to believe that it's also very accessible. Mike says it is, so there we go. Autocomplete is very difficult. So hotels.com, I have that as an example. If you start typing in a location to search for a hotel, you really have no idea what's happening on the screen. Now, if you can see the screen, what you know is happening is there's a drop-down box with a list of six or seven matching locations. So that's really difficult, but the flip side example of that is Expedia. If you start to type in T-O-R on Expedia, and you get the same experience, you see the drop-down, but Expedia does one better than hotels.com. Expedia says ten results, eight results. As you're typing in the numbers, again, they're using that live region idea. As you're typing in, sorry, the letters that make up the destination you're trying to go to, they're announcing to you how many results are available. And that kind of goes back to affordances. If you have no idea that there's a drop-down of suggestions, not only is it hard to interact with it, you literally don't know that it's there to interact with it. However, in the Expedia example, and this is what we do in Drupal as well, we announce, as we start to create that list of search suggestions, we announce to the user how many suggestions are in the list, and that not only does that help them to understand how big the list is, it helps them to actually understand whether the list exists or not. So I think those are some great examples, and if you'd like to see those examples or experience them from the point of view of a screen reader or user, I'm happy to walk you through those after this. Really the key thing that I want to drive home here to David's point when I asked if anybody had thoughts at the beginning, JavaScript is not the problem. The fact that there's a, whether it was Ruby or JavaScript or Java or, you know, insert language here, the language is not the problem. The fact that we're trying to create, the fact that we're all trying to push the ground boundary and create excellent user experiences, we're trying to do things a little bit differently, we're trying to make things a little bit more dynamic and easier for people to interact with, and that there's additional effort from an implementation standpoint that we have to put in in order to make that a reality, that's what the problem is. And I think that, to Mike's point at the beginning, that problem isn't a technology problem, it's a human beings problem. It's an issue where we really just need to work together to define what good looks like. So David, I think earlier this week, I think I saw on Twitter, David over here posted an article about WCAG 2.1 and we're getting close to a final list of additions to the web content accessibility guidelines. That's working together, that's people collaborating on what good solutions look like. The Drupal community, for years now, I think there's been a concerted effort to ensure that when we release Drupal, yeah are there bugs and glitches? Sure there are, there's bugs and glitches and everything, but there's been a concerted effort to ensure that when we release Drupal, it is at a high degree of quality from, you know, a security and performance, but also from an accessibility standpoint. So I really believe that it's working together, I've put some links up there for some common frameworks, Angular Bootstrap, React, etc. But it really is working together, A, to educate ourselves coming to sessions like this and talking to people like myself or David and B, just working together as part of these communities to ensure that we're moving the ball forward. Things don't need to be perfect, but I think that we just need to always be doing better, and as long as we commit ourselves to that, then I think that we're going to get to the place we want to be. I know that we probably only have a couple minutes left, but any questions for me? How did you know about the mass like of what it did, what got you there, and what do you like about it? Yeah, that's a good question. So the question was, how did I find mass.gov and what do I like about it? So I'll show it to you afterward, David, but I've been looking at mass.gov for a couple of years now, actually, I don't live, tend to live in Massachusetts, but I think it was Sarah Bourne who tweeted it a couple of years ago, and it struck me that it was a really good implementation, or let me say a really good execution. Maybe the implementation could be different. They're kind of doing some stuff that technically you're not supposed to do, but they're doing it because they found a way to solve the user experience problem and use the tools that were available. So I like it. It's easy. It's clear. You navigate it with the keyboard. It speaks really clearly from a screen reader perspective. I really think just as far as people that have gotten it right and people that have gotten it wrong, mega menus no matter how often they're used on the web, they actually are a really difficult pattern to get accessible, and particularly if that top row of items has two behaviors. When your top row of items has a click-through behavior and a hover state to drop down the menu, that's the hardest challenge to solve, because now you need to find a pattern that works for visual users using a mouse, visual users using a touchscreen, screen reader users, keyboard-only users. You need to find a pattern that works for everybody, and it's actually exceptionally difficult to find the right pattern there. Are there any other questions? So you mentioned a lot of case studies, and you're comparing and crafting. Do you host a kind of idea to talk to each other? So the question was, I've put a few comparisons there. I wouldn't call it good sites and bad sites. I'd call it accessible user interface components and not accessible user interface components. Just let nobody try to sue me. But no, I don't. The question was, do I host kind of a GitHub or a page somewhere that just provides examples of good and bad, what good looks like, what bad looks like, and the reasons why one might be better or more preferred from an accessibility perspective over the other? I don't have that, but I think that is something that's a good idea. And on my ever-growing-to-do list, I'll jot that down because I think it would be easy to host that. And then other people in the community could come along and do pull requests against that and add things. Any other questions before we wrap up? Well, I hope you learned a lot. I'll be sticking around for the rest of the day. So happy to answer questions, happy to show people some examples. Happy to not publicly shame you, but maybe more privately shame you if you want me to take a five-minute look at your website and your web application and tell you where maybe some soft spots are or low-hanging fruit areas for improvement. Thank you very much.