 So this is great to have the last presentation of the day. My name is Jesse Beach. I work at aquia. I'm one of the front-end developers. They're working on the spark team and For the most part I work on JavaScript CSS and HTML. I wouldn't say that I am at all an accessibility expert But what I am is someone who's very interested in data and access and people getting two information that they need and information that they want So I kind of fell into this accessibility space in October of 2012 at the Toronto Camp the Drupal Toronto camp We were working on the toolbar and we had to meet the accessibility gate the Drupal accessibility gate. I Had no idea what that meant at the time So I spent a full day working with Everett as you felt Mike Gifford a bunch of other people And I really got a sense of how far from the mark we were in Terms of accessibility and how rich the space is Providing means of access to complex applications like the toolbar in Drupal core And it started me down this road of wanting to Make all of Drupal accessible. I know I'm not the first person who's wanted to do this I'm certainly not Perhaps the best person to do this, but I'm someone who jumps into something You know, even if I'm stepping on toes and knocking over glasses who Wants to see you know Good UI be made so this is a Talk about what we're doing at the moment in terms of accessibility in Drupal and what we might do into Drupal 9 with perhaps Setting up, you know an initiative something bigger that gets us formal structure behind these efforts So if you go to this bit.ly URL I set up a Google document With notes, I would love it if you know You feel like you have something to say or something to add if you could add your comment to notes on this page I'll lock down the page afterwards and open it for comments But it'll be a place where we can go back to and find names of people or organizations Ideas we can incorporate into later plans So just give everyone like two seconds to jot that down What I'll do is talk a little bit about what we're doing at the moment and then some efforts Beyond the reason we want to improve accessibility in Drupal Core is because it is simply the right thing to do There is you know, you can talk about perhaps Economic reasons you can talk about You know you as a provider wanting to move into a space such as government that requires you to be accessible But from my perspective as a developer there is no Justification for building something that someone cannot access in my mind so if we look at a project like WordPress and I think Mike Gifford for bringing this up during our conversation yesterday if we look at This plug-in in WordPress called WP accessibility has 3049 downloads out of 20 million downloads for WordPress core and About five million six hundred and eighty-three thousand domains that are running WordPress The reason I bring this up is it was suggested in our conversation that the accessibility support in WordPress is not ideal And if you think about that as a percent there are point zero five three six percent of WordPress sites running this module Potentially to improve the basic accessibility of WordPress There are currently six hundred and fifteen thousand domains running Drupal and to my mind Solving this problem in core means that we hit all of those domains all of those sites It's not something that we want to push out to contrib space in terms of support So we are building the standards in Drupal core One of those is the WCAG the web constant accessibility guidelines and the a tag or the Authoring tool accessibility guidelines There's a page on Drupal.org that specifies that we support these two guidelines in terms of accessibility But we really don't know if we do that's the problem The problem is we we don't measure our support of these two guidelines in terms of Drupal core And what I'd like us to do as we approach Code freeze in Drupal 8 and then the cleanup phase is to think about how we might measure our support of these two guidelines Before we produce the official release of Drupal 8. So what we might do is a full review of all core admin pages every route that we have run it through a Ballotator an HTML balladator run it through a tool like the wave tool on Firefox And just get a baseline Number of how many errors there are on that page and Then log an issue for it We would also want to do a full review of the core templates to make sure that things like field templates Have the attributes that are necessary to make those things accessible And then what I'd really like to see is an effort similar to the HTML 5 effort and the twig conversion effort Where we create essentially a scoreboard of every template and every page in Drupal and Give it a grade, you know, or it's percent of support if it has three errors in the wave toolbar then it has you know a Negative three score and we want to get them all to zero. I'm not really sure how we would measure this But we want to have some way of comparing them and knowing when we get to done for Drupal 8 and I would say that the number of people working accessibility in Drupal core that I see regularly which is definitely not everybody but You know, it's maybe a dozen Who are there in the queues every week? I Would love to see people who are Actually accessibility experts jump in and help us do testing help us do reviews I don't think you would need too much knowledge of code to jump in load up an admin site run it through a toolbar to check for errors and then Log those somewhere on triple org So I mentioned a couple of tools. I was just introduced to the wave toolbar and Firefox Essentially what this does is it looks at your rendered HTML page and it Indicates through Warnings and errors on the page where you might have problems such as missing an alt tag on your images We also have markup validators These to me are useful They won't bring out errors and highly dynamic pages because they're just going to look at the rendered content that comes back from Drupal And then moving into the future. We might look at more automated means of doing testing The quail module. This is a JavaScript framework that does testing Talked with them Peter Drogman's about perhaps working this into the test for a module which we've begun developing front-end tests against and then moving something that like that perhaps into the text test spot for Testing patches as they're proposed another interesting Tool for the content creation side would be whizzy wig integration letting authors know at the time of Authoring that an image that they've just added to the page is missing alt tags So at the moment there are about 116 open issues with the accessibility tag against them Some of these are meta issues. Some of these are highly specific issues But to my mind they don't represent at all the full amount of work that we have to do against Drupal 8 and then we get down to this Idea that the guidelines themselves are extremely difficult to understand. I myself Have read them perhaps, you know four or five times over and I still don't really understand what they're trying to make me Do or what they would like me to do Those being the the WCAG and the a tag guidelines so what I've tried to do is and This is through talking with Mike and Vincenzo is to understand the principles behind the guidelines and to Apply those in my work rather than the specifics. So those are a UI should be perceivable You should know that something is there If you come to our talked women are giving a talk tomorrow about views oral UIs Backbone will give you really stark examples of how things are not perceivable currently in Drupal core Operable refers to being able to take action against something in the UI Understandable if you could imagine a Link in a comment that just says one new, you know There's one new comment and that link repeated ten times on a page with no further context You've eliminated the possibility of understanding what that means to an on-site aduser And then I think robustness is just the general principle of UIs in general, but especially for The UIs we don't spend the most time on you know the visual UIs for oral UIs we want to make sure that They Are accessible and Usable always in the same way. We don't want to be introducing new patterns or anti patterns Into these UIs so I would say that as Front-end developers were extremely invested in producing highly polished usable visual experiences But when it comes to building Experiences that are non-visual oral UIs keyboard UIs We don't have the experience and we don't have the patterns available to us to do those That sort of work. So if I was to list the major Components or the systems in Drupal that need Work at the moment like actual design work views is at the top of the list and thankfully the views team is in complete agreement that the accessibility of that subsystem of Drupal is We'll say nicely lacking at the moment. We know that what the major issues are They're going to be hopefully addressed during this Drupal con one of them being switching to using the dialogue API That was introduced to Drupal 8 in views that will open up the possibility to work on further issues That are sort of blocked at the moment by that there's still a bit more work to go with the field API and specific fields to to make sure that they have all the attributes and The descriptive accessibility elements and then I really want to look at The subsystems like content creation Block placement the things that people are going to do on a daily basis and make sure that those are highly refined usable There's nothing hidden everything can be found and it's kind of a dream. I would love to be able to have an Oral UI for field states in the same way that we introduced You know Ajax support for fields or states for fields where if you know you click a checkbox you you can associate Another set of field items with the the state of that checkbox. It would be great if we could have automatic Informative information based on fields produced orally as well as visually Yeah, and views we have to fix that. I don't know if there are oral UI designers I think it's Exactly so When we say UI designer, we're implicitly saying visual UI designer, right? Someone who comes in produces boxes and arrows and you know layouts but that's just one way of Producing data output a view of data an oral UI is something that you hear is another way of accessing that information and We tend not to think of an oral UI as something you can design because I don't think We've really taken the time to design it if you think about visual UI 40 years ago when the first mouse and click interfaces were introduced No one knew what they were doing. They were inventing metaphors. They were inventing patterns to take bits and present them to people in visual presentations and I want us to do the same thing in Drupal. I think we are going to be pioneers in this space of presenting information through oral means And by the same token we need to think about How we access information from a keyboard consistently throughout Drupal Are there hotkeys and combos that we can build in so that if I press C or S or A they do something consistently in views and content creation across the board So if anyone knows of an oral UI designer or someone who produces spoken UIs Bring them into Drupal. I think they have the opportunity to really impact a lot of people around the world So the short-term plan this is to do with just getting us to Drupal 8 launch Meeting our proposed or our professed support of WCAG and ATAG Is to make sure we're testing and this is where we need everyone in the community because we do not have the resources at the moment to both build and test at the same time People out here if you work for a university if you work for a company if you have access to testing facilities Anything at this point will help us log an issue and once the issue is logged There are folks who will address it You know, we have a small number of folks, but they're highly efficient and they they really burn through issues And then what I really think we need are folks Who develop in the modality that is their primary modality my primary modality is visual I? want to understand how people interact with data in different ways, but It's very hard for me. It takes a lot of interaction and Learning and I feel like I just I will never get the UI perfect for someone who wants to access data in a non-visual way We're starting to see that people coming into our community whose modality of interaction is non-visual Who are also developers and this excites me so much because they bring? Patterns of usage to our community that we are lacking at this moment. So if you know someone developer Who wants to spend a little bit of time volunteering bring them into Drupal let them know that there are developers who will teach them all of the You know intricacies of working with Drupal in order to get them being productive and producing code The long-term plan. I really think we need Something that has the formality in the structure of an initiative in the same way that we had mobile whiskey scotch For Drupal 9. I want to see meetings Well, I hate meetings, but they're very useful. I want to have people getting together talking about these issues Laying out priorities. That's what I really like priorities Getting issues in the queue in order and addressing them, you know tops about them All right, so I'm gonna open it now to questions That we can save for posterity and if anyone is inside the notes Please take notes on questions and we will address them later Wanted to bring up. I hope this is appropriate Perhaps a larger movement that's around this that's often referred to as universal design And I wanted to point out. I think this is a great no pun intended visionary effort that's going on not only for Blind users or for people with motor limitations for using websites But also for the future of Drupal when it comes to vision This is an oral UI And it's very hard It's very hard for blind users Common It's really hard for blind users to use Typical devices and these typical devices will become harder for visual, you know for visually Normal people also to use as they get smaller And if we are actually ready with universal design, we'll be the We'll be the first CMS on the Apple watch for example or for other devices that Rely less on our ability to touch them and see them and more on our ability to hear them and interact with them Vocally so for what that's worth So following up on the previous point there Would Oral design do you think also include, you know, the device in that case is speaking Functionality of the system and that's hard enough as is but if you're dealing with a touchscreen or Something like that where you don't have a physical keyboard then Inputting data of some form is just as hard if not harder Should we be looking at? You know, what would it take to make Drupal Voice capable for when there is such a tool that allows that I have no idea what that would look like I have no idea what the standards are there if anything, but is that something we should be asking about at this point? Yeah, definitely. Okay. I mean that excites me as a developer So I don't know. Are there any specs along those lines for, you know, browsers not just outputting data In the audible format, but also inputting data. I don't know if anything there. That's not Google proprietary So just to repeat that Mike said that Dragon naturally speaking is one such input modality there was an effort by Everett Sioux felt to Collaborate with them, but that didn't go anywhere Okay, and personally I don't know anything beyond Google proprietary, you know voice API's builds into Chrome where we could do that, but Yeah, I would love to see. Yeah, I mean where I'm kind of going is You know, what would it take to give a Drupal site the kind of interactivity that something like Google now has probably an awful lot But it'd be really cool if we could Definitely everybody Thank you also for your all your hard work This is something that's been on my mind as long as I've been working in web But I've like I've never found anyone willing to pay for it. So like and and the biggest Practical struggle in my experience is that so much of accessibility has to start with content authors Like even just the base, you know the alt tags, you know If you're uploading an image so many people are just gonna skip it and they're not gonna put it that in But Mike, you know, my clients don't want to pay me to make an alt tag a requirement for them to upload an image So like it like to me though like you nailed it when you talked about testing because But like as much I mean, I've read WCAG and it's like two pages long. I mean, there's nothing hard in there like technically Like as there, do you know of any work around automated testing of scan this page for accessibility errors? and because I mean if we could make that a feature where You check this box and every time you have an accessibility error, you get warned or you get whatever to me that that would make That would bring the at least the awareness level up and you know, that would it would give us a place to start Yeah, so Falcon brought up yesterday this idea of doing almost like an error log of accessibility problems during content Authoring so that if you did have a workflow We know where an individual content creator didn't produce the optimal output You could have an editor come by and perhaps fix that or at least maybe inform it out to a third-party service That would do that sort of thing if you needed to the the two realms of content creation and site building To me aren't defined well enough yet in terms of our community to understand what the different Responsibilities in those two areas are and I think that's something that we need to suss out still So my question is sort of about the I guess the known unknowns and the unknown unknowns I work at a university and I'm curious to like do we have the Tests in place in the real-world stuff like I can I have a usability lab So I could sit students and people in a library who are using JAWS or Any of these tools down in front of a in front of more or something like that and actually test them and get that I guess distributed to the community But do you guys have that yet is does anybody have that as a post anywhere or do we is that a contribution that needs to be made? I think that's a contribution that needs to be made posting those videos Somewhere would be some that's completely valuable something that someone could run through and Create issues off of and have as a physical artifact to go back to yeah if you could do that Awesome, so I thought I'd give a status update because I'm the person responsible for making accessible content And then disappearing for a year But also run quail. So quail actually has a branch with key with Q unit integration now So that it would be really easy to integrate with test swarm But I think a challenge would be it as a community is to Identify test suites beyond just straight accessibility guidelines But also that incorporate best practices that are not Necessarily encompass and we cagger 508 And I think it would be we we have had in d6 Modules that gave feedback to theme developers and to content creators So those should be catching up with d7 and d8 shortly, but I think it even beyond test swarm integration even looking at Some form of like qa.drupal.org For people who are just writing interfaces would be also interesting thing to look at Do you think we could support dynamic interfaces? So quail too, which is in JavaScript already does support that and we have tests written and that are working in Travis CI that that do do a lot of dynamic interface Ajax loaded stuff The challenge is figuring out how to You you do need to train the test about what areas of that content Do you want to look out for and what events you want to react to so that would be you know another challenge? Awesome, let's talk after this. Yeah, I just want to say um, you know I think it's great that we're talking about getting testing in place to make sure that we're Satisfying accessibility standards. I just had an audit done on my site and I am I was trying to think about what can we automate in terms of future Pages and I realized that a lot of that stuff just can't be automated like a lot of them are design-centric, you know color contrast issues Sensible navigation order so a lot of these things have to do I think Design and I'm wondering You know is the appropriate path of that education towards like Drupal designers Or like on the contrib space is there way that we can evaluate like contributed themes in terms of their accessibility Because I think that's a big piece of it that can't just be automated Yeah, there's good points. I don't think I've answers To me anything that any sort of educational material needs to be so immediately perceivable and consumable That folks don't have to you know think about it too much But that doesn't mean you shouldn't do it at the very least we can make sure the core themes Satisfy the design definitely to me those those are part of core and those would satisfy but I hadn't Really separated the two in my mind yet so I thank you for bringing that up that there's only so far we can take automation and then Education is the only way to to bridge that and and testing like with usability labs as Mentioned before I mean that's a big part of it. Definitely even exposure. I mean that just produces exposure to the larger development community Has a value Thanks Thank you very much. Jesse. This has been good. I just wanted to to add the yeah No one level in terms of the the automated testing will get you so far. So there's a lot of stuff that we can do to go off and to To help with automated testing that identify the low-hanging fruit in the basic basic elements But we need to To also try and engage with the communities who have the people with expertise who can deal with this It was great to have somebody at the back was was talking about you know trying to engage their their usability lab and trying to go off and bring in students with with Disabilities to be involved, but there's a lot of different kinds of people and a lot of different kinds of disabilities that there are blocking people from having access to to to your website and and the Blind the blind community certainly one, but it's not the Necessarily even the hardest of the the the types of people that you need to that The WKG is dealing with so there's dealing with people with cognitive issues and learning disabilities and with people with multiple disabilities There's a range of potential people to try and and to try and work towards being able to to make your content make the content accessible but wanted to go up and to talk just briefly about the was about Looking at at the the the standards and a lot of these things are becoming Are still forming and I think that that I'm in conversations with people at a tag who are or the WC3 You're sort trying to define these these definitions and define best practices There's a really interesting opportunity to go up and have a tag be reference or to have a tag reference Drupal and Drupal's admin interface as as sort of the This the best best practice by defined by the WC3 in terms of implementation of these these tools I think where we're further ahead than any other CMS out there and there's still so much more to do But the WC3 doesn't have that many implementations to to sort of point to so Maybe just wanted to raise those those issues So what could we do to help people who want to test but are faced with you know the totality of Drupal and They need to somehow distill that into a 25-minute session Do you think we could put together a list of? You know subsystems or even just list like our top 10 admin pages That we would love to see tested and that will get the ball rolling. It would certainly help if we we haven't had a Full audit of Drupal 7 period that it has not been audited by an external party for accessibility And there was an effort that the accessibility team tried to put together to have a An audit, but it comes down to Who's who's gonna fund it and it's something that you know somebody who is a good auditor will charge In the range of you know $400 a page to go off an audit And there's a lot of pages just in core if you're looking at you know all of the different admin screens And that's you know potentially thousands of dollars if you haven't prepared and organized and I mean It's you know hundreds of thousand dollars if you haven't prepared and organized But you know it's a it's a it's something that that needs to be thought through strategically And there needs to be a team to are willing to commit it to deal with that and again with Drupal 8 You know it's it's many of the same problems are We're relying on people to go off and to give their feedback to the Drupal community There's an issue and trying to make sure that we've reached out to them So if there are problems that they they know that they can can reach out to the Drupal community and get a positive response and and we've Certainly for most modules and most themes when we've identified an accessibility problem People are really quite generous to go off and to deal with to try and address that so yeah All right, let's talk about that more. This will be the last question. We're four minutes over This is actually I guess more of a response to the question of how can we get people to do testing and Get some coverage one thing that I'm working on a distribution at a university Customized distribution that we have developed a training guide for And the training guide covers a lot of the core things that content creators do every day in Drupal and so something like Taking a training guide and pointing something to that and say okay you can evaluate the process of using this of this this process by following this training guide and how you might you know to With whatever your assistive technology is and can you do these core functions like adding users creating content editing content and Rather than necessarily looking at it as we have to evaluate all these admin pages To more look at it in a usability standpoint of we have these tasks that people need to do and we already have a lot of documentation Help documentation that we could just point people to and say hey, can you evaluate this process using your technology? That's a great idea. I think that would really be a great place to start To make sure I get your card before you leave Great. Thank you everybody While I still have power of the microphone. I told Brian Hirsch that I would announce a sprint on Friday Tonight 730 coders lounge in the double tree hotel Drupal cons Oklahoma tornado support codathon We'll be working to help the victims and emergency responders on the ground We want to develop a website that will coordinate the transportation and help deal with housing issues. If you have time tonight double tree 730