 Good morning. My name is Wim Leers. I'm a senior software engineer in the office of the CTO of AQUIA and working on Spark. And I'm Jesse Beach. I'm a front-end developer on the Spark team also at AQUIA. And we're here to talk to you today about how we're trying to make data and interactions accessible to everybody. So is that better? Awesome. Right. So the first thing I have to admit is that I am not a usability expert. And really neither am I. What we are are two developers who are extremely passionate about building usable, accessible, beautiful, delightful interfaces in Drupal. And I'm sure that everyone out there in this room, front-end developers, UX developers, community management people, docs writers, you're also interested in making accessible interfaces as well. But what we're really talking about is building what we like to call rich experiences. So this means an experience that is satisfying to someone regardless of their range of abilities. Sorry. Sorry. I'm just going to scroll down. So let's talk a bit about whether or not Drupal is accessible already. And the answer to this is yes in a way. As a community, we have lots of processes and guidelines in place that help us to produce an accessible product. One of these is a pledge that exists and it reads, an inclusive community. As an inclusive community, we are committed to making sure that Drupal is an accessible tool for building websites that can also be accessed by people with disabilities. We also have an accessibility checklist within Drupal. There are 11 items on this checklist. Some of them include that all non-text content has alternative text, that all data tables have headings, that users can complete and submit forms, and so on. These guidelines are here in order to provide us with a quick means of assessing the UIs and the tools that we're building. We also have tags for issues that relate them to accessibility. For instance, the Needs Accessibility Review Tag, the Needs Color Accessibility Review Tag, the A11Y tag or the ALI tag, and we also have a tag that's just the word accessibility. Using these tags identifies them as needing further input from people who can test or that they pertain to usability within Drupal. We also have an accessibility pledge that module developers can assign to their modules to call them out as supporting or in the future, perhaps, supporting usability. For D7, we had the D7AX tag, and in D8, we'll have the D8AX tag. We also have a pledge for module developers. This reads, I pledge to make this modular theme as accessible as it can be. If you find any flaws, please submit an issue, link to the issue queue, and help me fix them if you can. There are a lot of tools and a lot of means of indicating that something pertains to accessibility of calling to action folks that can help in this process, and it kind of reminds me of a pillow fight in a sense, because everyone means well. We're all trying to make accessible, usable interfaces, but when you get down into the nitty gritty of the details of doing this, it gets messy really quickly. We're trying not to hurt each other, we're trying to be gentle, but that still doesn't mean that it's easy to do. So this is where we transition into talking about oral user interfaces. Oral is a word that means to hear or it pertains to sound, and we contrast this with a visual user interface, which begs the question, does Drupal speak? And the answer is you betcha. So I really quickly want to let everyone have a listen to what Drupal sounds like when it's speaking. Hello. This is Drupal. Welcome to Portland. And thank you for attending this session. Wim and Jesse are very excited to talk about oral user interfaces, and remember, put the bird on it. Awesome. Just a little string that a screen reader was reading to us from Drupal. We have to question why we should consider speech as an output method for consent in Drupal. Because semantic HTML, you know, might be enough to express the meaning of the page or the consent in the page. But I'd like to give you two examples that illustrate why semantic information is not enough in terms of creating a rich experience. So we have here a screenshot of the admin interface. This is the config admin interface in Drupal 8. And we see that it's fairly simple. We have links that go to different forms within the config interface, account settings, site information, cron, text formats, and editors, the fairly standard configuration main screen. Now let's take away all the visual styling. And we see here a page that is the stripped-down, non-visual, semantic HTML for this configuration page. And I wonder if anyone would find this acceptable, any visual people out there would find this acceptable as an end user experience to sell to a client or to use on a daily basis. And I think most of us would say the answer is no. We expect to have our information chunked, presented to us well within the confines or the capabilities of the user agent that we're using, and in fact, optimized to the user agent that we're using. So let's have a listen to an example of Drupal speaking to us in interface, and we're going to take away the visuals. We'll start with the visuals, and then as we go in, we'll take them away. And I should just note here that this is a Drupal 8 interface. We're looking at the Tor module. I don't want to pick on the Tor module in particular. This is just the example that I pulled out. There are plenty of aspects of Drupal 8 that have really great support for spoken and semantic interfaces, and some that don't. And this just happens to be one that doesn't. And if it doesn't play within a moment, we're going to go to iMovie. Let's get out the full screen here. I don't know if you just want to pop up the open project. Sorry, I'm just going to reopen it. There we go. Okay. This one. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. You know, to talk about usability and accessibility, even iMovie is fighting me the entire way. All right. Great. I was watching everyone's faces as they were listening to that. I saw people sort of skeptically. And then as we got to the fifth or sixth dialogue, people started to wonder where in the world we were in that interaction. And that was exactly the reaction we were going for. It's very easy to get lost in an interface when you don't have the visual input, and then to not even know why you're there after a while and to know when you've finished. If we look at the markup for the tool tip that was part of the tour module, we see that we have taken steps to make this accessible. It's not just dibs on a page. We have a div with a role of dialogue. We have aria, semantic attributes. We see p tags and ht tags. There's an attempt to make this cementically accessible. But when we take that semantic underlying element and put it into an interaction, suddenly moving between those elements doesn't have any meaning. So as we've been thinking about this problem, women and I have attempted to visualize what or how Drupal does in terms of its visual versus oral interfaces and to plot them on a scale. So we've plotted them on a scale from inaccessible to delightful interaction. And if we imagine that inaccessible gets a value of zero and delightful interaction gets a value of, let's see, four because we're engineers and we count from zero, we can plot the visual content consumption experience, the visual administration experience, the oral content consumption experience, and the oral administration experience. And we see that in our opinion, both of the visual experiences, content and administration, both fall within barely usable to almost delightful, with the content consumption being the one that has the higher upper bound. If we compare that to the existing oral experience, we see that the upper bounds make it just too acceptable interaction. And the lower bounds range from barely accessible in terms of the content consumption to inaccessible in terms of the oral administration. And what we're trying to do in our work in Drupal 8 is to raise the lower bounds of these experiences to at least barely accessible as a minimum. And we would like to get all of these to barely usable because when we get to barely usable, that's when we can start talking about usability and improving these interactions towards that level of delightful, not just making them accessible. We really wanna hammer home this idea, this is something we've internalized, that accessibility is not just a word that means non-visual. What we're talking about is making interactions and data accessible to everybody. And what complicates this is that the dynamic applications that we're building into Drupal 8 undergo state and property changes. So it's not enough just to mark up information semantically. We also have to describe the transitions from the states that they begin in to the states that they end up in as we move through a dynamic application. And an example of this, and if it doesn't play, I'm not gonna bother with it. There's a video on the screen that's meant to show infinite scrolling. This is something that's very common in modern user interfaces. You can imagine something like Facebook where you scroll to the bottom of the page, or Twitter, and new items automatically get added to the bottom of the list. And as a visual person, you know this because you see them fade in, you see the list expand. It's obvious to us because we've been given cues to understand that the state of the page has changed. For a non-sided person, those cues also have to be provided by different means. And the best way to do that is to tell them through their user agent that things have been added to the page. So what it comes down to is that changes in state have to be expressed. Because what we're doing is we're building interfaces to data regardless of the means of expression for everybody. We wanna talk specifically about how we do this, how we show and announce the changes that are happening to the data and the interactions. So I'm not even gonna bother to try to play this. We're just gonna pop into iMovie really quickly. All right, so what we're about to see here is a video of new interfaces in Drupal 8. We're gonna start on a basic page. In the video, we'll tab around a bit to some of the items to show you that we're tabbing to the home link and to perhaps an edit link or an article link. We're then going to constrain the tabbing to just the contextual links by entering what we're calling edit mode. And at that point, the user interaction is constrained just to those pieces of the interface that are required to complete the interaction. The contextual links for the individual articles that contain things like edit, quick edit, configure. We're gonna edit one of those articles and go into the overlay. Inside the overlay, our choices and flow of interaction are again constrained, just those elements in the overlay. We're gonna exit the overlay back to the contextual links so we won't be able to tab through the entire page. We're still in the flow of editing. And then we're going to edit exit mode back to all of the links in the page if it wants to do that. Oh, this is so frustrating. Doesn't even wanna do that. I don't know what I'm gonna do. Let's see if we can exit. The definition of crazy is when you continue to do the same thing over and over again, expecting a different result. Let's see if we can somehow increase the size of this. So we're thinking that this selection is the thing that was preventing us from doing that. I don't have anything in full screen. Awesome, thanks. I don't know why the quick link would work and the menu item wouldn't, crazy. But we're gonna make this do this, I promise. We're gonna turn the unusable into usable. Log out, make, navigate, edit, button, not pressed. Pressed, tabbing is constrained to a set of 15 contextual links and the edit mode toggle. Press the escape key to exit. Main form, article form, article form, article form, article form, open five best cauliflower recipes, configuration options, button, not pressed. Open, quick edit. The overlay has been open to edit article five best cauliflower recipes. Tabbing is constrained to items in the administrative toolbar and the overlay. Skip to main content. If you have dismissed this message, close overlay, button, view, edit, open, devil. Navigation, five best cauliflower recipes. Main, title, this field is required. Five best cauliflower recipes, edit text required. Application, tags with hint, edit text auto completion list. Exited application, navigation, home, exit navigation, edit, view, close overlay, button, navigation, edit, button pressed. Tabbing is no longer constrained by the overlay module. Main form, article, article, article form, navigation, edit, button pressed. Not pressed, tabbing is no longer constrained by the contextual module. Mic, exit, log at home, hop home. So, I hope that was inspiring, interesting. We've been working on making these sorts of interfaces accessible now for probably three months and we're not sure if what we're doing is correct but we're hopefully moving the conversation in direction where we can start to talk about interfaces like the one you just saw. So, let's move on to talking about how we did that because that's the stuff that really gets us excited. If you don't know, ARIA stands, or ARIA is a set of technologies that enables us to create accessible, rich internet applications hence the acronym. And what ARIA does is it represents states. States like being active, being disabled, being pressed. It also allows us to represent through markup properties. Properties like a label or a form or a dialogue. ARIA attributes take non-semantic or vaguely semantic HTML and turn them into semantic, meaningful markup elements. We'll see if this wants to play. All right, so this video doesn't wanna play and I don't wanna go through the pain of trying to get iMovie to run. So what we were going to show here was the new toolbar element. We have in the toolbar element tabs across the top of the page if you've seen Triple-8. And we're using the ARIA pressed attribute to describe whether or not an A tag is pressed at the moment. In the JavaScript, we determine if the ARIA pressed value should be true or false. And when it is true, it expresses that that A tag element is an oppressed state as if it were a button. One of the most useful and I think underused ARIA elements is the ARIA live attribute. So ARIA live describes an HTML element that should be announced to the end user, the content of which should be announced to the end user when it changes. And it's very simply ARIA dash live as an attribute with one of two politeness settings, either polite or, and I always forget this, assertive, right? Yeah, assertive. I don't like to be assertive so I never remember that that's one of the values. So we use the ARIA live attribute to enable Drupal to speak to the end user. And we do this through a method on the Drupal object called Drupal announce. This is a method that's been built right into Drupal 8. I think we got this committed a month and a half to two months ago. So let's have a quick look at it. It's very simply a method on the Drupal object and we pass that method as string. And that string will be read to the end user as soon as the announce method is invoked. And because we want to be cognizant of translation, the string should be passed through the Drupal t function before it's passed the Drupal announce so that if it is translated, we get the translation read to us instead of the English string. The Drupal live announce elements where these strings are getting written to are just, is just located inside the body. So when Drupal announce is used for the first time, this div gets created and appended to the body element inside the page. So the idea for this first came up when we were developing the toolbar for Drupal 8 back in the late fall to early winter of 2012. I traveled up to Toronto to attend the Toronto camp and the accessibility sprints up there. There were a bunch of folks, Mike Gifford is in the office right now, Everett Zufelt's, I'm forgetting some people and I apologize, but there were a bunch of us there who were looking at the accessibility of the toolbar and this was one of the first times that I as a developer had to address issues of accessibility in a very real and concrete way because anything we built for Drupal 8 has to pass the gates, the accessibility gates in order to get committed. So we discussed this Drupal announce idea and built it right into the toolbar. In the late winter of 2013, we had the time to pull that out of the toolbar, make it into a general function and get it committed. And the first thing we learned upon getting that committed was that it didn't work. And it didn't work because if you call, if you replace text in a Drupal live elements or an ARIA live element quickly, all of the strings that got placed there before the last string in the series don't get read. So if you have four modules that call announce all one after the other, three of them are going to be silent. So we had to step back and figure out how to solve this problem for all of the modules in Drupal. And the way that we did that, I'm not exposing any of the details down here, but we essentially queue up all of the announcements within a 450 millisecond period and then all of those get appended to the ARIA live element and read in succession. And it works pretty nicely. And it highlighted for me the fact that we need to solve these problems in Drupal core because if we leave, contribute to solve these problems, we don't get the benefits of a common solution. We get competing solutions and loggerheaded solutions that are going to step in each other's toes. Now I want to just mention this and I know that probably most people in the room don't have the false assumption that accessibility that requires JavaScript is not really accessibility. If we look at surveys that have been done recently, asking people who use assistive technologies whether or not they use JavaScript, we see that 98.6% of people that use a screen reader also have JavaScript enabled. And I think the number that have JavaScript enabled who don't use a screen reader is something like 98.4%. So folks using screen readers actually have a higher percentage of JavaScript usage than people who don't. So you can kind of take the idea out of your head and not worry about it. So Drupal announces one of the tools that we built into Drupal 8. The other is the tabbing manager and I'm gonna let Wim speak to that. Thanks, Jesse. Quick swap of seats. So Jesse explained to Drupal that announced a component which is really important for accessibility in Drupal 8 for dynamic pages. And that was really about oral updates, about communicating change. But what is also really important is to guide the user to assist the user in navigating around the page. So guiding the flow, helping him or her navigate around the page via the keyboard. Because both screen reader users really need the keyboard, but power users might also want to use the keyboard. So I might prefer that. And that really brings us to the other big accessibility components, Drupal.stabbing manager. So why is it necessary? Well really because the specification is, it looks like this essentially. Depending upon the action to be performed by the dialogue, the object with focus before the dialogue box is open should be saved. This will allow restoring focus to this element when the dialogue box is closed. And if your eyes glaze over after hearing and reading this, that's perfectly normal. The spec is very vague. It says what should happen, as in X and Y should happen, but it doesn't specify how this should happen. Browsers don't implement this. It's really up to you, the developer, to implement this in JavaScript and make it happen. So that's why it needs to exist because managing tabbing is really difficult. If you have a contract module, we don't want to have every contract module developer solve the problem in their own way because then that will lead to conflicts and it would lead to reinvention and it would just cause problems. So what we did was take a tabbing manager. We wanted to build something like a tabbing manager. What we did was take what already existed in the overlay module in Drupal 7, which already had tabbing constraints, pull that out of there, put it into an API that is easy to use and then make sure that module developers, when there are multiple modules using tabbing constraints simultaneously, do not run into problems so that it always will work well. So what the tabbing manager really tries to do, it's really simple, this is the essence of it. It helps you with constraining tabable elements to just those that are necessary to complete a task. So it helps restricting keyboard navigation to aid with a specific task that you're currently working on. And if we would look at an example, then this would be the one for the overlay module and this is a visualization that shows which elements are tabable. So we're looking at the overlay module, the overlay is open, and what is tabable are the elements, the buttons in the toolbar and the elements that are tabable within the overlay, but the elements on the underlying page which were tabable just before opening the overlay, meaning tabbing around the entire page, those elements are no longer tabable right now. The tabbing manager has constrained it to just those elements within the overlay. So that's a high level overview of what the tabbing manager tries to do and what it tries to help you with, but let's dive into a quick how-to that shows you how you can use triple dot tabbing manager. So a tabbing manager, as you would guess, is about applying tabbing constraints and we'll be looking at an example here. The examples before have already used the contextual links module and we'll do the same here. This is a piece of code that helps with the edit mode toggle, the pencil icon, the top right of the toolbar, and let's quickly analyze this function. At the bottom of this function, you have an if test and within a if test, we're calling triple dot tabbing manager. That's the interesting part. So triple dot tabbing manager dot constrain is what you want to call when you want to constrain tabbing to a specific set of elements and we pass in a selector that specifies these elements are the ones we want tabbing to be constrained to. And what it returns is what we call a tabbing context and the tabbing context is a basic building block that the tabbing manager uses to keep track of things and to make sense of things. So we get back the tabbing context and we store it and that's all that happens. Now, if we look at the whole, what happens is at first we retrieve the tabbing context if any, if that exists and if it indeed is a tabbing context, we release it. So we always release the tabbing context and then if we have just entered edit mode, if you have clicked the edit mode toggle, meaning that you want to constrain tabbing, then we will apply a tabbing constraint. So there's two things to do. One, constrain and two, when you no longer need it, release the tabbing constraint. Constraining tabbing is one part of the equation but as Jesse already explained, when dynamic changes happen on the page such as infinite scrolling and so on, a screen reader user is not necessarily notified of this change. So how do we communicate this? Well, with the Drupal.announce component that Jesse just explained. You could do it something like this. Calling Drupal.announce and always passing it through Drupal.t to translate it of course. And we just inform the user that tabbing is a constraint, B to which elements it is constrained and C in this case what we do is we provide or we inform the user of a handy keyboard shortcut to exit the current tabbing constraint. So keeping the user informed is very, very important. So we just saw the basic usage of the tabbing manager essentially and I think everybody sees that it's pretty simple to use and that's very nice but in the case of multiple modules using it simultaneously, how can it possibly go wrong? Well, it could go wrong in many ways if each module was implementing it separately but thanks to the tabbing manager and everything being centralized. What we do is we keep a stack of tabbing context and that's where the tabbing context object of before comes in. So initially when you access a page, tabbing is not constrained of course and you're able to tab across the entire page. However, once you for example enable the edit mode toggle, tabbing is constrained to just a contextual link. So at first you have no constraint on top of that, you now have the contextual links constraint and then when you're tabbing through the different contextual links, what might happen is you enable for example, in place editing and then the contextual links tabbing constraint doesn't make sense anymore. So we apply a new one on top of the previous one that allows you to tab to the relevant elements to do in place editing and once you stop in place editing, once you've finished doing that, we release that tabbing context, that tabbing constraints and the previous one gets applied automatically again. So once you've done your in place editing thing, what happens is you're back to navigating the contextual links. So I hope the video will work, but we have a quick video showing precisely that. Maybe I should switch to iMovie as well. Yeah, let's just do it really quickly. All right, so this is the same video we saw before but now we understand a little bit better what's going underneath. So let's watch this interaction and think about the code home, home, log out, like, navigate, edit, button not pressed, pressed. Tabbing is constrained to a set of 15 contextual links and the edit mode toggle. Press the escape key to exit. Main form, article form, article form, article form, article form. Open five best cauliflower recipes, configuration options, button not pressed. Open, quick edit, edit. The overlay has been open to edit article five best cauliflower recipes. Tabbing is constrained to items in the administrative toolbar and the overlay. Skip to main content. If you have dismissed this message, close overlay, button, view, edit open, dibble, navigation, five best cauliflower recipes. Main title, this field is required. Five best cauliflower recipes, edit text required. Application, tags with hint, edit text auto completion list. Exited application, navigation, home, exit navigation, edit view, close overlay, button, navigation. So as you can see, we were just in the overlay and now we've closed the overlay and if what I just explained is correct, then we should now be tabbing between the different contextual links again because that was a previous tabbing context. Edit, button pressed. Tabbing is no longer constrained by the overlay module. Main form, article, article, article form, navigation, edit, button pressed. Not pressed, tabbing is no longer constrained by the contextual module. Mic, exit, log at home, home, home. And just now we disabled the edit mode toggle again. We toggle it off and because of that, the first tabbing constraint was removed so we're back to page level tabbing. So really what we wanted, the message we wanted to convey is to embrace modalities, to embrace different ways of interacting with contents. There's different ways of output, visual and aural, but there's also different ways of input, meaning mouse and touch that are the most common ones, but it's also possible to have different ones, like for example, keyboard navigation, but maybe some day voice input, maybe. And the way we want to, the way we are currently proposing what we think should become a best practice is by using Macbook.js we make it much easier to actually support different modalities and to add support for new ones. So we're using Backbone.js for that and this is a brief quote from the lead developer of Backbone.js, I'll read it aloud. The essential premise at the heart of Backbone has always been to try and discover the minimal set of data structuring and user interface primitives that are useful when building web applications with JavaScript. So what really is important to us is the part where it says the minimal set of data structuring, which are in the case of Backbone models and collections, as well as views. So what Backbone does is it doesn't try to impose a highly restrictive structure on your JavaScript, it doesn't define your architecture, it doesn't confine you within a certain architecture. It's really up to you, we just use it to have basic building blocks because it makes it a lot easier for other developers to jump in and use it. It also invites better documentation because the separation of concerns is what is really important. The framework isn't really important, what matters is the separation of concerns and that's what Backbone really helps achieving. Before Drupal 8, what the typical piece of JavaScript code would look like was something like this, you would have DOM event handlers and they would directly be modifying the DOM again to do rendering and this is really something that is not very nice for developer experience, it's pretty painful. But now in Drupal 8, if you're using Backbone.js, what happens is DOM event handlers do not really do anything magical anymore, they don't go deep into the system and make changes. What they do or hopefully will do is change the state of a Backbone model because the Backbone model contains a state and what we can then do is to have Backbone views linked to those Backbone models, react to those state changes and do the rendering. So there is a clear separation of concerns and this really helps to make the developer happy. It's a much better developer experience. So if we look at a very high level of what Backbone would look like, it would look something like this schema. So what we're seeing here is at the top, talking to the server, that's what Backbone.sync is for, we don't use that, that's not relevant to what we're talking about. What's relevant to us is modeling states, modeling data and we use Backbone models for that. So a Backbone model reflects the current state of whatever dynamic application that you have. If relevant to your application, it might make sense to have many models of the same type grouped in what is called a Backbone collection. What is really important though is the connection between a Backbone model that is linked to a Backbone view. So whenever the model changes or a specific thing in the model changes, we can react to that in the view and that's really the essence of what we are using. The view can then in turn render changes and that's what's presented to the end user. So if we would look at an example of before Backbone and after Backbone, this is a piece of JavaScript code in triple eight. The top one is before, the bottom one is after and both are the same code essentially, both are a DOM event handler and they are what it looked like to react to the edit mode toggle. The one at the top though, what it does is it iterates over an array containing all contextual links on the page and what it does is it directly modifies a DOM, it toggles a class. Whereas the second example, what it's doing is just iterating over a Backbone collection looking at every model and setting a specific attribute. So we're not directly modifying the DOM anymore. What we're doing is we're setting states and there is then a Backbone view that can react to this. So we've seen a basic introduction and a lot of claims about what Backbone can do to help make you, how it can help you make interfaces that serve multiple modalities. So let's dive into a quick how-to on how we can use Backbone for better accessibility. The core premise is have one model that contains a state and many views, one per modality and maybe in some cases it makes sense to merge the support for multiple modalities in a single view. So what this looks like is a model for states, a view for supporting touch inputs, a view for supporting visual outputs, a view for supporting oral outputs and so on. It really depends on you, which modalities you want to support and it's easy to support for more modalities later on. So step one, create a model. The model contains a state and it's stupid. It doesn't contain business logic. It should be stupid. And it's really up to the views to update it because views handle input and outputs. So whenever input happens, we can update the model to update the state. Again, we look at the contextual links module and the edit mode toggle in particular. And as you can see, there are three different attributes, three different states that it contains. The first one is viewing. It's a Boolean that indicates whether edit mode is enabled yes or no. The second one is visible is again a Boolean indicating whether the edit mode toggle should be visible at all. And this is actually something that would seem bizarre at first sight probably. But the reason is when the overlay is active, you cannot have contextual links within the overlay. So it doesn't make sense to have the edit mode toggle be visible, be usable when the overlay is open. And this is the sort of edge case that is kind of tricky to support when you're not using something like Backbone. And then you have subtle edge cases that you need to deal with. But if you build it this way, it's very easy to reason about. So we have a Boolean for that in our state. Finally, the tabbing context. This is to track the tabbing managers, tabbing context if any right now. So three states, that's all we need. Step two, we create what we call a visual view. And this particular view deals with three modalities, visual output, mouse input, and touch input. And it looks something like this. The Backbone view receives a DOM element, the edit mode toggle itself. And the first thing we do is bind a click event handler. And this handles both the mouse of course, a mouse can click, but a touch device also emulates the click event. So this covers both mouse and touch inputs. And it does a very simple thing. It toggles the is viewing Boolean in the state in the model. So this is what enables edit mode or disables it. Next, we have the initialize method. This is what Backbone uses as kind of a constructor. So you can view it as a constructor. And what it does is it listens to the model to where the state is stored. It listens to any change within the model. And whenever anything changes, it will call the render method of the Backbone view. And the render method in our case does just two things. It's the bottom two lines. It toggles a class, which one, the element hidden class, to hide the edit mode toggle whenever relevant, whenever the overlay is open. And it finds the button within the edit mode toggle and toggles a class again. That indicates whether it's toggled or not. So nothing complex. Next, we create a keyboard view because we also want screen reader users to be able to use keyboard navigation. But in this case, it's not really necessary because the click event already handles keyboard presses. So if you press the enter key, that will actually also toggle the click event. So in our case, we're lucky we don't need that. And we also don't need to focus our blur support. We just need to know if the button was toggled. Yes or no. So nothing special needs to happen. Finally, we create an oral view for screen reader users so that we can provide oral outputs. And in this case, since we only have output, we don't have any event handlers. So we have still a initialized method and we listen to model changes again. But we listen to model changes in two different ways. The first way is we listen to any change in a model. And whenever that happens, we call the render method. The render method in this case toggles the aria pressed attribute. And as you can see previously, we were looking for the button element and setting the active class if relevant. And here we're again looking for the button element but setting the aria dash pressed attribute if relevant. And as you can see, there's a clear separation of concerns here. The previous thing only was relevant for visual output and this one is only relevant for oral outputs. So if someday the aria spec is updated to have all their magical properties, it's easy to come in here in this view and add support for those as well because each modality has its own view and things are not tightly intertwined anymore. So that was the first model listener, the first change handler. The second one listened specifically to the is viewing attribute and that one was the Boolean that conveys the edit mode whether it's enabled, yes or no. Whenever that changes, meaning we enter edit mode from previously just viewing or we exit edit mode from previously being editing, we call the manage tabbing method and that's the exact same method that we saw before in the tabbing manager example. So what it does is it always releases the tabbing context if any and if and only if we're entering edit mode then we apply a new tabbing constraint to those elements relevant. So now we're already doing the tabbing constraint but we also want to make sure that whenever a tabbing constraint is applied, we again use Drupal to denounce to explain this to the user because it's a dynamic change. So that's really all there is to it. Everything will remain in sync automatically because the model contains a state, it's easy to hook up new views to support more modalities, to extend views, to make them better because everything is in a central place and everything else just listens to that and updates that. So that's really all there is to it. And we wanna, Jesse and I really wanna make clear that this is a best practice that we're currently proposing but this is not a final thing. It really depends on you guys, the developers to help us improve this and make sure that this is superseded by even better ways to deal with this. So we really need your input as well. Finally, if for me at least, Jesse will continue afterwards. If this sounds relatively scary to be working with if you're not familiar with using screen readers yet you still would like your applications, your dynamic things, your dynamic modules to become accessible, as accessible as they can be, then we have a good thing for you. We have a module that will do console.log. We'll use console.log meaning logging into your web browser's console whenever a triple of the nines call is made. It will also visualize any tabbing constraints. Whenever the tabbing constraints change, the CSS animation will occur. So you get actually visual feedback for something that isn't visual. It will highlight the things that are tabable in a red box shadow. And the one that is currently focused will get a different color back box shadow. So whatever you're doing, it makes this makes it really easy to use these new accessibility components. The URL fell accessibility with that back to Jesse. So I hope we've expressed here that a UI is a site and it's sound and it's touch. And then Drupal 8 is going to communicate through all of these modalities, using these shared tools that we're developing and the structured framework underneath. And the question is, is your module going to use these as well? So my preferences and let's move on to questions. If you do have questions, come up to the mic in the middle of the room. And if not, this presentation is available on GitHub. The whole thing, we have a link to it on the session page. Hi, this stuff looks amazing. Thanks. One thing, last time I looked into it, it seemed like, I don't know if it was half and half, but some screen reader users use the arrow keys to move up and down the screen. Is there anything we can do about that as far as constraining it? Or would you have to tell them to tab more often if they want to take advantage of features like this? You know, the answer to that is I don't know. As I've been interacting with people that use these screen readers more and more, I've realized that tabs are not necessarily the primary modes of navigating a page. And I'm really not sure how we could capture those key movements as well, but I have to assume it's within our grasp to do that. And we could, but I think we need further research. Yeah, maybe they'll just start using them more since the arrow keys just kind of go through the source, so it's hard to direct them. It's true, I don't believe that they use the tab index the way that the tab key does. And the way that we're able to constrain tabbing is to manipulate the tab index on the page, essentially setting the tab index to negative one for the things that we don't want to have tabbable and not setting a tab index on the things that should be tabbable so that we maintain the DOM order of the tabbing. But I think fundamentally we want to support how people work, and if the arrow keys are the way that they work, then we need to figure out a way to do that as well. Cool. Can I ask one more, since? Yeah, definitely. Is Backbone, is Backbone going to live with jQuery in Drupal Core, or is that something just with the accessibility module or? Actually, Backbone.js got committed to Drupal Core several months ago, so in that sense, yes, it's definitely possible to use it, and yes, Backbone and jQuery both exist in Drupal Core right now, so we're actively using it. Great, thanks. Just a quick question. Would this accessibility, would it play well with internationalization? I mean, will they work together so that you can have all of your text in a place where it can be easily translated? Yes, if it doesn't, it should, and we believe it does. So everything we're passing to the oral interfaces is going through the drupal.t function, and that is the standard means of translating strings to different language. It doesn't translate your strings for you, they have to be translated, but if they are translated, you'll get that. Just wanted to ask me, the drupal announce is being really quite useful, and the tab infrastructure, I think, is also a great addition to where we're going in. I'm glad to hear the explanation about the use of Backbone.js for this, but in drupal.t, there's still quite a lot of interfaces that are gonna need to be updated to add this in, and I don't know as the Drupal accessibility maintainer how many interfaces there are within drupal.t that would need to be changed to add this interactive element in there. Is there any way to go off it, or has anyone cataloged the number of interfaces or the number of dialogues, the number of types of interfaces that we should be potentially looking at applying this to? I mean, is it an order of, is it 10? Is it 100? Is it a thousand? And then just, on that level, would be useful to know how much work there is to go off into, I mean, now that we have the centralized tool, how do we have it consistently applied so that module maintainers stumble across it and know about it so that they then go off and are asked to go off and apply it in their own interfaces? So to, I have to admit, I don't have the answer to that question. We don't know how many interfaces there are that we would need to design. What we do have is a buff coming up on Thursday at one o'clock, check the board out front. We need everyone interested in this topic to come and help us solve these problems to measure the extent of design that's necessary to figure out the priorities for addressing them to code, to test. If you were to present Drupal Core to someone without any CSS and say, all right, go, go create the CSS, style it, do that. Your draw would hit the ground because you would think, oh, we need designers, we need developers, we need testing on every possible device. I think that's the kind of challenge that faces us right now. We're essentially presented with raw markup and we're trying to create something useful out of it or something dense and rich. You know, it's not a small feat. Well, any of this get ported back to Drupal 7 and for those of us developing in Drupal 7, what can we be doing now to push this forward? So when Drupal 8 comes, it's not gonna be this huge cliff. I don't think any of the functions we've got so far depend on anything in Drupal 8. No, it's easy to backport them, yeah. It should be easy to backport them. But the question is then, of course, we specifically built it, for example, the tabbing manager. Drupal 9 is something that is pretty standalone so anything can start using it. But the tabbing manager specifically has a mechanism to deal with multiple modules, having tabbing constraints at the same time. So in the case of, for example, the overlay module and the overlay having its own tabbing constraints right now, which is where we learned from, essentially, that might cause you to run into problems when using something as well as something else, something new custom, as well as the overlay because that already has its own tabbing management. So Drupal 9 shouldn't be a problem. Drupal tabbing manager could be a problem, depending on what you need to do. I want to thank everybody for coming. Do attend the buff on Thursday if you're interested in these topics. We're going to be talking about prioritizing testing, getting tests set up and written, and essentially creating the plan to bring a Drupal 8 to a level of accessibility support that we profess to have. It's not going to be a small effort, but I think it's a manageable effort. It's something we can accomplish before the release of Drupal 8. And just briefly, as Jesse mentioned at the core conversations thread yesterday, there's over 100 accessibility issues in the Drupal 7.8 issue queue. And so in terms of things that can be done and how people can be involved now, Drupal 8 is a great place, but there's also a lot that needs to be done in Drupal 7, and there's also modules like the accessible helper module that need help and need sort of work on adoption, but there's quite a lot of room that can be done right now to go out and to get involved. And it would be great to have somebody step forward and look at backporting the work that you guys have done in Drupal 8 to Drupal 7 and to maintain that moving forward for the existing users. Yeah, and in case you don't know how to find those issues, I just showed it on the screen. You go to Drupal.org, the Drupal project on Drupal.org, so that looks like this. Drupal.org slash project slash Drupal. You go to the issues, you click on the advanced search tab, and as the issue tag, you enter A11y, accessibility. Accessibility is better. Yeah, as I found out yesterday. Okay, both of us apparently didn't know that until yesterday. So accessibility, you search, and then you find all the issues. Great, thanks everybody. Thanks.