 All right, thanks everyone for joining us today. My name is Lauren Shea. I work for the Drupal Association. And today we're talking with Mike Gifford about Drupal 8 Accessibility, leveraging your Drupal 8 site and making it really accessible. You can reach out to me at any time about our webcast series, our Global Training Days, which is our initiative to grow Drupal Adoption globally. Any Drupal camps you might be working on. And this is a couple ways to contact me. I'm on IRC and Drupal.org as LCA. You can obviously tweet me at LCA Drupal. And here's my email address. Again, thanks for joining us. Just a little bit of housekeeping. If you're listening from your computer, select the mic and speaker audio option. And you'll be muted during the call, but there's an opportunity to ask questions and talk to Mike if anything needs some clarification. Just use our Q&A window. And then additionally we have a post-webcast survey that asks a couple questions just to find out that we're providing the right content for our webcast series and a couple of specific questions Mike has about our accessibility features in Drupal. Please make sure five questions will take five minutes. And just a note, we have some upcoming Drupal cons. We have Barcelona coming up in September. Drupalcon Asia in Mumbai right now. We don't have a specific date that we are holding February 2016. And Drupalcon New Orleans, which should be really exciting in May of 2016. So we look forward to seeing you there. And just a quick note about our Drupal 8 Accelerate program. We are raising money to accelerate the project, improve our project and make sure that people have the right amount of funding to be in the right place at the right time to work on Drupal 8. So if you haven't donated already, take a look and see if you can donate to make sure that the project moves along smoothly and promptly. And without further ado, let me introduce our guest speaker today, Mike Gifford. Mike is president of Open Concept Consulting. He is a Drupal 8 core accessibility maintainer and advocate for benefit corporations. And you can contact Mike at mgifford on Twitter. And that's his website. So Mike, I will let you take over. Thank you, Lauren. So first of all, Drupal 7 was pretty good. We did, it is still the most accessible CMS out there. The WordPress folks are referring to Drupal's accessibility and trying to emulate that. And they're coming along pretty quickly with their accessibility. But they've got a long ways to go because of the work that's being done on Drupal 7 and getting Drupal 7's accessibility up and ready. But Drupal 8 is going to be even better than Drupal 7. There's a bunch of stuff that is built into Drupal 8 that we couldn't get accomplishing in Drupal 7 and that are just really large benefits for anyone who's implementing a Drupal website. And stuff that just sort of is coming out of the box. We really worked to try and make Drupal be as accessible as possible by default. And instead of having something that was an add-on that you needed to install afterwards or work with as an extension of Core, we wanted it to be an integral part of Core so that the sites, whether they were intentionally or not intentionally built to be accessible inherited the best practices of web accessibility. So part of that comes with HTML5 and that wasn't something that was available for us to work with before and it was a huge effort to go off and to convert both the front end and the back end into HTML5. I'll be going into that in a bit more detail later. Another one is Way Area, which is the web accessibility initiative of the World Wide Web Consortium. Their area is the accessible rich internet application. So that suite of tools gives additional semantic information which can be useful, largely the screen readers, but not just the screen readers. There's an opportunity to use this additional semantics to give context and information to people who are building websites and we've brought a lot of that in there. Drupal is also coming with the latest version of JQuery UI and when Drupal 8 comes out that will be something that also has a number of accessibility improvements in there. There's a great team at the JQuery community that is looking at accessibility issues and working to improve that library and the Drupal community is working with them to try to test and evaluate the code base for that. One of the things that made Drupal 7 so good was the Forms API and the Forms API, so many of the elements for creating and developing a web form in Drupal is done through the centralized application programming interface that allows us to really have a lot of control about how forms are processed. But we've updated that to give a lot more context and a lot more information which really helps with the accessibility. Finally, there's a number of CSS tools or centralized tools for CSS and JavaScript that you can use when you're developing your modules and your themes that will make it easier for you to convey in a systematic way information to screen readers and to control how keyboard only users are able to navigate your site. With that, Laura, if you could go to the next slide. ATAG is a new thing that what we were striving for with Drupal 7 and Drupal 8 is WCAG requirements which is the web content accessibility guidelines and ATAG is part of the same suite of guidelines but they're looking for how to go off and create an authoring interface that encourages people to create accessible content so making the tool itself a better tool for authoring accessible content and Drupal is responsible for both creating content as well as displaying that content so it's really both an authoring tool and a presentation tool. But we've begun to incorporate elements of ATAG which is just a candidate release phase of the World Wide Web Consortium but what this allows us to do is really begin to engage with the best practices of the web accessibility community globally and try and look at implementing things that make it easier for authors to create that accessible content. So one of the things that we've done is just, as I said, go off and make sure that the administration interface is accessible. We've always in Drupal 7 and 8 tried to make sure that a blind user or somebody who has it used as assistive technology can both install a Drupal site, be able to do the administration of the Drupal site, edit the content around the Drupal site so obviously read the content of the Drupal site as well. So it's really looking at the whole experience of both being a user and also a developer of the Drupal platform. One of the nice things we've added in for ATAG is requiring alt text. So we want to try and encourage best practices wherever possible and one of the things we noticed after Drupal 7's release was that the most common accessibility errors that we ran into when people were watching a new website was that they forgot to use the alt text when they were uploading images and so there's a few places that will talk about that where we've included requirements for alt text and that helps with getting this, with moving towards ATAG compliance. We've also added help documentation in line. There are, again, times where if you knew what to do you were able to go off and create something and an author was able to go off and create more accessible content but if you didn't have an idea of what the content was capable of then it was really difficult or what the tool could do. It was difficult for authors to know where to begin and how to start creating that to adopt those accessibility best practices so by trying to change the documentation we're making it easier for your editors to go off and create better content. Next slide. I mentioned HTML5 a bit earlier but it's really about trying to build in more semantics to build in more meaning so there's things that we were able to go off and bake into Drupal 8 like the phone number field and email and URL and search and number and color. There's a number of HTML tags that we can now use when we're building websites and that is part of the API. Another big change that we made was switching from field sets to details. In every previous version of Drupal there was a collapsible elements were done through field sets which used to be an all right way to go off and to manage segmenting a group of content that you want to be able to hide to minimize the amount of content on the screen. Unfortunately nested field sets don't work particularly well for assistive technology so it was a real barrier for trying to use field sets properly in Drupal 7 but with Drupal 8 we've eliminated that problem and it's easier now for radio buttons and check boxes and multi-part form elements to be wrapped in a field set so that there's that semantic relationship built within them. But again, this is something that was new to Drupal but also in many ways new to web development and that the details tag is one that when we first implemented it wasn't as well supported because HTML is still an evolving set of attributes. The final element I wanted to talk about under HTML was the required element so we can now semantically go off and in the HTML explain when an input form is required. This is really good for accessibility particularly for users that might have JavaScript disabled so making sure that there's a way that universally without JavaScript you can identify to a browser which are the elements that need to be filled in. Now we're going to be looking at that going forward because there's an outstanding issue to try and take that default HTML output and actually wrap JavaScript around that so that you can have a nicer user interface that provides more usable information and more accessible for users that have JavaScript enabled but that's just the beginning point of that. We haven't yet gone and we're able to bring we're not able to yet find a solution that works for Drupal just yet to wrap the HTML5 required elements. Next slide please. So area is the accessible rich Internet of Applications and we've added a few, there's a few of them actually that are already in Drupal 7. When you're doing the initial installation areas is being used to announce when there are your progress as you're doing the announcement so if you wanted to hear some of the initial implementations of area you could hear that in the installation screen to sort of hear the progress. In Drupal 8 you've added it in a lot of other places and we couldn't add it before because the area standard hadn't been finalized. It wasn't ready yet to go off and be baked into Drupal 7 but it's now something that was stable enough that we were able to go off and bring that in and so area landmarks are added to both the core themes and core blocks and area landmarks are basically describing information and the kinds of content blocks or types of content that are around so it could be that there's a search as a type of landmark and the footer is a type of landmark and people are able to navigate through using a screen reader that can navigate through the website and find out semantically whether you're talking about a menu or whether you're talking about related content or whether this is the main element itself so it's really useful to present that information to screen reader users so that they have that context. We also, there was initially a discussion about trying to take out the HTML, the header elements because we're also in Drupal 7 introduced a number of header elements to allow people to navigate through the website and unfortunately at this stage we're not able to remove those header elements and in a lot of cases those header elements are still being listed at least in Drupal 7 they're listed as element invisible so you don't actually see them but they're there so that there's that semantic information presented on the page but screen reader users use the landmarks and the heading structure differently to understand how a page is built and to navigate with that. We've also used area described by to provide description of fields and so if there's an input form as a description field that's all semantically linked so that a screen reader user can understand that there is a piece of related content and what a description field is tied to semantically also to core blocks. I'll be talking about area live a little bit later so I won't go into more about that but it's essentially to provide a way to interrupt the user and to make sure that if there's an urgent issue that needs to get passed to a screen reader user that they can be... what is being read to them can be interrupted. We've also added area sort which gives you the ability to convey when you're changing the sort order of a table and if you want to change the order of things this gives that information semantically to the browser or to the assistive technology so they can understand what is happening. Next slide please. Image support is one of the low hanging fruit of accessibility. All text in some ways are so simple and other ways are somewhat... well, quite complicated. It's difficult to know how to describe an image and what are the best ways depending on the content that it's presented with because sometimes a picture is something you may not want to actually just describe the picture you may want to describe what the picture says in the context of the text that it's embedded in but we've made a number of big improvements to the Drupal interface with Drupal 8 in that all text is required by default on content types. So when you're setting up a new content type or are using the default ones that come with Drupal they come already enabled with all text and having that all text be required by default. Now this can be turned off so you don't have to go off when you're creating new content types have required text for that but it's something that establishes that default so if you're just implementing the best practice that won't include all text. If you for some reason don't want to use that you can just disable that but it's that extra step that makes it easier to go off the easiest thing to do is to implement something in an accessible manner. With CK Editor there was also an all text that was... we're now requiring all text by default there and you can disable that but it's a bit more complicated to disable the all text for images in CK Editor and we did this because we couldn't find that many instances where it would be... well there's a way to go off and disable them in the user interface on an individual basis but by default it will go off and you'll be forced to overwrite that as you're adding the images in CK Editor. By default the CK Editor is going to ask you for an all text and it's something that for most instances when people are adding images unless you're really familiar with what are the kinds of... the places where it's inappropriate to use all text on images and there are a couple fringe cases where it's not appropriate to go off and use all text like if it's a... if it's only for decoration you don't need to include all text in that but we've tried to set it up so that it's... the user is going to be encouraged to go off and to add all text in places where for 80 or 90% of the time you're going to want to have that all text there. You'll also find in Drupal 8 that there's longer text for all text and that it's translatable. There's also now support for the theme image function so that's something also we've added in there. If you can go to the next slide. So views is now in Drupal 8 and it's amazing but part of bringing views into Drupal 8 is meant that both the user interface and the output have met a higher requirement because contributed modules don't need to go off and to meet the goals of WCAG 2.0 AA standards but we're really hoping that everything in core itself is meeting those requirements. So we've had to do a lot of work to add more semantics to the user interface so that blind users can start to use views. This hasn't been a major sticking point for people who are using views in Drupal 7 right now. It's a real challenge to go off and use it without either disabling JavaScript or being a sighted person. So the improvements we've made there we've also made improvements on the output so the tables in particular have been made considerably more accessible. There's now the ability to go off and set caption and summary tables and the summary elements, there's always changes in code and what is the best practices and in HTML4 there's a slightly different way to go off and handle summary and caption elements than there is in Drupal 5 because in HTML5 there's a slightly different best practice so we've adopted the more recent best practice. We've also made sure to go off and include header and ID elements to improve the semantic information, the semantic relationship between tables and it's not like most of the time the tables in Drupal are all that complicated and some people have argued that they're not actually necessary for some screen reader users but there have been enough people who do use them or just have them consistently implemented by views tables will definitely make it easier for machines of all sorts to be able to identify where they are in the context of a data table. Views is also using a common modal dialogue which helps to again for consistency make sure that they're using a default Drupal dialogue that is consistent across the board for users. Next slide. So Forms API is great and accessible web forms are really quite complicated but we've simplified a lot of that for most people and part of that is the introduction of area. We went off and had an issue with the asterisk and the star that appears in Unrequired Texts and there's sometimes these little things that depending on who's evaluating the website and what they're looking for it has been a sticking point on some evaluations of Drupal 7. So we've been able to find what I think is a best practice for this in terms of actually displaying the asterisk through CSS and creating the asterisk as an SVG file that is displayed in a really mobile friendly way and it expands really nicely and blows up and looks really crisp at a large size but it's also very accessible the way that we've created it. It's something that I think is a nice best practice moving forward in terms of presenting just the information that a screen reader user would need to see without providing an unrelated star like usually when a screen reader was reading it out it's a star and when it's the required text and that has been understood to be required because it's just a convention that's being adopted but it's much more orally understandable right now where it says clearly read out as required text. We've also made the configuration of the description text configurable so that you can through the user interface sorry not through the user interface through you have to code it but it's possible to determine whether you can have the description field appear in different places. We've also added title to all form elements so that there's a label and a title having a title with form elements means that there's always going to be a label that's associated with that form element to see that there's a semantic relationship and we're not going to be having input forms that don't have any corresponding title with them to give context for that field and again we're supporting HTML5's required field and the big change that's actually happened this week is we've made a one of the epic issue queues is making inline forms inline accessible form errors so that when people are filling in a form if they receive an error that we now have an accessible means to go off and convey that information back to the user so that by default in Drupal 8 the results are going to be much easier for everyone to be able to understand where the problem is and how to go off and address that and there'll be a simple link provided that draws people down to the source of the error and allows them to be able to make that correction so that's a huge issue that I think is one that all Drupal 8 sites are going to be benefiting from and probably one of the bigger accessibility improvements that people will be able to identify even as sighted people when they're navigating through a website. Next slide. So when you're logging into the the authenticated side of a website there are a couple things that were annoying not only for people with disabilities but especially with people with disabilities things like auto-capitalization and auto-correction on usernames and passwords these are things that when you're filling in a form with a mobile device it can be really frustrating to see that we've also added a better description to the password checker so that is more semantically meaningful when people are filling in the form they can see clearly that they have both a visual and textual explanation about what the change is whether or not their password is good enough or not and there's a certain other improvements that we've made for the administration side of the website and the two bars is certainly one that's gone through quite a lot of reviews and improvements to see that there's a very modern and very accessible menu built into Drupal 8 to allow people to navigate through their website in a really clear and straightforward manner. Next slide. So one of the mammoth issues that we dealt with in Drupal 7 was dealing with CSS display none and there was a decision to go off and to eliminate that or to change the phrasing of CSS in Drupal 7 we created Element Invisible and Element Hidden we created our own sort of nomenclature for how to go off and to hide content on websites and whether it's the the heading pages that I mentioned earlier that we wanted to have there for semantic reasons but we didn't want to to have them we wanted to hide them for sighted users but not to hide them to screen readers or another one is the skip links that are built into Drupal 7 we wanted to be able to have them visible on focus but not see them at other times it was something that we felt was a better it was useful to have a pattern built into Drupal 7 that allowed us to have one standard way to be able to have an accessible way of hiding content for everyone for screen reader users and also for keyboard only users to make sure that there was a mechanism to do that in Drupal 8 we decided we looked outside of the community like we've done for a lot of the Drupal 8 process and decided that it was better to adopt the language and the nomenclature that the HTML5 boilerplate did so in this case the language is hidden visually hidden, visually hidden focusable and invisible there's really not much difference between hidden and invisible you're going to find that when you're doing your upgrades from Drupal 7 to Drupal 8 that there are going to be places where the old element and build invisible classes will need to be renamed to be the new format using hidden or visually hidden to make sure that it's clear when people are using the new standard because we're not going to be the element invisible classes are no longer part of the Drupal 8 framework we've also in the UI there's the ability when you're creating a field label formatter to actually determine whether or not that field label is visually hidden or not so there's a drop down that allows you to specify that so that's made it a lot more useful we're creating content types and wanting to be able to control how that information is presented next slide another big change that we've added is around the JavaScript and the tabbing manager is something that Wim largely developed and in this case it's allowing people to or trying to go off and dealing with more complicated user interfaces and with more complicated user interfaces you need to be able to control the tabbing structure in a way that allows it to function like in an isolated piece in terms of the if you have a list of links that pops up you may want to be able to tab through that list of links and then go up to the top of that set of links and cycle through that until that set of links is released and provided some code to go off and to address this and there's also examples in the in Drupal 8 about how to go off and to manage the tabbing manager so again this is a JavaScript function that allows you to control the function for keyboard only users so next slide please I should also just say that just in case people don't know there's a number of people who use keyboards to navigate there's certain people who might have carpal tunnel syndrome or might have something like cerebral palsy who are not able to navigate through a website using a mouse but certainly people who are blind as well are keyboard only users there's people who have much more limited movement who also navigate by essentially tabbing through a list of links and navigating by jumping between links on the page and that's what I was referring to earlier on the previous slide about tabbing through the interface the next JavaScript tool that we've added is Drupal Announce and this is using the area live functionality to be able to communicate directly to the screen reader and to give them information about what is important information that might need to get passed along so this is an example of this but we're really hoping that when there's interruptions or announcements that are being made to a sighted user when there's content that changes on the screen but this content can get reported back to the screen reader to let them know that there is new or different content on the web page it's something that when we're creating information on a website so many of the web pages are now so dynamic that the content is being changed as we navigate through it and providing a means to explain to a screen reader that there is a change and they might need to go off and review the content on the page because of an update it's really quite important to have that context and give that to them and again in the middle of that slide I've provided an example of how to go off and use the Drupal Announce function and again Drupal is an effort to try and make Drupal multilingual and so in this case Drupal 8 is definitely the most multilingual version of Drupal ever but the example we've used here includes translation as well now I didn't actually include a slide on this but since I'm talking a little bit about translation it's useful to remember that there are accessibility implications for multilingual sites and multilingual content if you are using a different language within the context of a page the screen reader needs to be alerted about that and there's easy ways to go off into either within a span tag or within at the header of the page to go off and identify what is the language that's being used but it's so important because the screen readers just try to read the content out using the libraries that they have available and they could go off and if you gave them the instruction that the text was in a different language it would try to read it in that other language but that's a fairly short description of that if we could go to the next slide so another neat initiative in Drupal 8 is the proudly built elsewhere and Drupal has really worked to try and play well with others and to collaborate and really engage with other open source communities to try and build the best tools out there and so you'll hear more in Drupal 8 about the use of twig and the use of symphony and those are elements that don't really have an accessibility component to them because they're deeper than that, they're the structure of the HTML not the HTML, it's how the HTML is created as opposed to the HTML itself or how the page content is created but it's where there are elements where the Drupal community has worked hard and I mentioned jQuery UI before CK Editor is another interesting one there was a lot of discussion that was really on about which whizzywig was Drupal 8 going to use and how are we going to ship with the whizzywig to be able to take advantage of all of the possibilities if you're able to control the whizzywig within that interface and make sure that the information is properly synced up it just makes the user experience so much more professional but we really worked with the CK Editor community to push their accessibility and to improve it but also to make sure that it worked well within the Drupal context and the CK Editor community has worked long on improving their accessibility and they've done a great job of it but it's something that does require perpetual vigilance because the whole environment is changing all the time, the browsers are being updated, user expectations are changing the markup is changing as well so many things are being reworked as we go and it's really important to be working with a large community to try and make sure that the tools we use are following with the best practices out there so again we mentioned HTML5 boilerplate and trying to go off and to pick from those best use cases I mentioned CSS lint in here as well CSS lint isn't, there are instructions being included in Drupal 8 to use CSS lint but it's not like that libraries being included in Core itself but it's part of the development process that we're using now to try and make sure that the CSS in Core is really shipped as cleanly as possible and there's now tools in CSS lint thanks to working with the Drupal community that are looking to see that the focus and hover effects for CSS are mirrored to alert developers when the user is only looking or it doesn't include pairing the hover and focus elements for CSS next slide there's a lot better markup in Drupal 8 we've had a team of people who've been looking at cleaning up and eliminating divs and making sure that it's a much nicer interface to be able to theme and to control but part of that cleaner markup is that we have more meaningful HTML and so it's easier for screen readers to be able to navigate through imagination, through breadcrumbs, there being improvements to the book module and to the forums there's also being improvements in taxonomies and also sort of cleaning out croft like empty headings and labels that were inappropriately labeled and so that was things that we've done to clean that up next slide you also notice in Bartek that there's underlines in the content of the links in the content itself and it's really a best practice that we're trying to go off into to emphasize and reinforce is to make sure that there are underlines in links to make sure that that commonly understood convention is used by default in themes so that we can move forward and sort of have that as a best practice moving ahead when people are thinking about designing their own themes and trying to keep in those underline links and the way we've done that does make it look a little bit better and a little bit more readable than the default ones that are presented with the browser next slide so color contrast is one that has been an interesting one because it's often overlooked and with so much of our population aging with the baby boomers it's a bigger issue to try and make sure that people with no vision or people with different kinds of vision are able to go off and to see the pages as well as possible so there being places where we've noticed improvements that can be made with gradients and are watching how gradients are calculated or are evaluated when we're looking at the creation of Quorum we've also made improvements to error messages and to just even the gray text to make sure that that content is something that's going to be available we also changed, you'll notice that Bartek has a little bit of a different blue than it does in Drupal 8th and Drupal 7th and again we wanted to make sure that not only could you could somebody with low vision see this fairly well but that it would be easier when we're out using our iPhones or our tablets out in the sun and needing to make small changes or whatnot to a website that we can do that because we have the ability we have the contrast to be able to see not just in a dark room with our bright screens but in a real life environment outdoors in the sunshine and that color contrast is becoming an important part particularly as Drupal 8th has a mobile friendly focus and I'm wanting to make sure that accessibility is part of that next slide so this is where I mentioned the keyboard only focus and CSS lint and it is really important to keep an eye on the focus of the keyboard so many times when people are doing the CSS they forget about the focus element and only look at hover whenever you have a hover effect defined there should be a corresponding focus event so that a keyboard only user has as good or better ability to go off and see where they are on the page because really the focus element and the outline are really the only ways to go off and make sure that a keyboard only user who is sighted knows where they are on the page when you're testing your modules and things it's useful to try and tab through the interface so just hit the tab key watch where the focus goes and see how so many people are navigating your website without the use of a mouse next slide so Drupal 8 isn't finished yet we all want to have it out the door and get running but it's not done and there's a lot of issues that we know about that are being pushed back to Drupal 8.1 because we now have a new release cycle so that there will be point releases of Drupal or even to Drupal 9 because there are just large enough issues that in order to tackle them we don't think we can tackle them within the 8.1 8.2 release cycle for Drupal but there's still things that can get into the 8.0 release and there's a list of issues a lot of them need review, a lot of them need the ability to test and evaluate and you don't have to be an expert in order to do this. There's lots of ways for people who have some experience to get involved and to look at that. So I've included the URL to get to probably the best source of accessibility issues in Drupal 8 and it's go.gl slash 1 lowercase b 1 lowercase j m lowercase b so do take a look at that it's also if you run into issues it's important to post those issues or concerns to the issue queue. That's the only way that issues get addressed in the community and that goes for modules and themes as well and as modules are being rewritten for Drupal 8 there are people who are using Drupal 7 to look ahead to say well this didn't quite work in Drupal 7 we weren't able to go off and address the accessibility issues let's try and do this when we're rebuilding it for Drupal 8 and look at how we can go off and leverage what's in core to go off and make it easier for everyone to be able to access it. There's also the last year to being some really interesting tools that are either open source or open source friendly that can be very useful to test and evaluate your module or theme or to look at Drupal core itself the best one in the community is Quail and it's a great library that's got a lot of advantages to it but the two that have come out recently is Tenon which Carl Groves is behind and again that's a JavaScript testing language or a library but it's a service so in that case you have to actually pay or sign up to go off and to get the results of that and there's a program there's an organization called DQ that has created one called AxeCore that they've only in the last couple weeks released and it would be interesting to see people try and evaluate and to test with these open source certainly the AxeCore and Quail.js are open source libraries but to work with those but reviewing core patches and to participate in the community online is really quite useful. There's also going to be a number of opportunities to learn or to read about web accessibility and to learn about ways as well as you can. There's a number of accessibility camps that happen across North America and Asia as well that are worthwhile looking at. There should be a few in the fall probably in Boston and D.C. and Toronto and Los Angeles so they happen in a few different places and meeting with people with disabilities and engaging with the accessibility community online is a really great way to help keep yourself up to date. There's so much information which has been posted about web accessibility over the last 15 years. It's difficult to keep up to date because so many times you're dealing with a Google search you get a result back which isn't necessarily as current in order to keep up with the best practices for the state in age. Next slide. This is our question and answer slide so if there's an opportunity for people to ask questions earlier and at this point nobody has asked a question in the window but Lauren you have a question for me? Yeah I did just one second. No problem. It would be handy if you had the use of the monitor you were expecting to have. Yeah no I appreciate your patience with all of that. So I did have a really quick question who other than blind years will benefit from these changes? There are so many people who have accessibility issues either temporarily or permanently that will benefit from these changes. The blind community is really a miniscule portion of the population. There are people who have low vision whether it's seniors just even looking at the percentage of the male population is temporarily blind. I think it's about 7% of the male population has some form of color blindness than the rest of us which just care less about color. But the percentage of color blindness within men is significant. You also have people who are temporarily blind or temporarily blind or have lost some of their vision temporarily medications they're taking or based on an accident they might have had or even if you're dealing with having cataracts removed or something like that that you need to deal with your glasses get broken and you're without your glasses for a period of time. A lot of the improvements that we're making in here make it easier for everyone to be able to adjust their web to what their needs are at the moment. So it's at least 15 to 20% of the population that is benefiting from some of these improvements because of the range of issues that we've been tackling with this. Definitely. You mentioned ATAG but is that a requirement for this? ATAG is not a requirement. It's something that we've wanted to try and use in order to help authors create better content and more accessible content. But that isn't something that the Dripper community has endorsed. And probably it's new and fresh enough that the standards haven't quite been adopted and there aren't good models to implement this just yet. So we need to have a few more examples in the community of how to engage with these guidelines. It's something that I expect will be a bigger part of the experience for Drupal 9 particularly as more agencies begin to look for this. And certainly governments and universities have led the efforts for adoption of accessible standards. And I'm assuming that this will happen in the next year or two. There will be a greater institutional push for these offering tools to be built in a way that it encourages people to use it. It looks like we do have a couple questions. I'll just start with this one. In Drupal 7, I ran into accessibility issues with the file attachment tables. Icon alt text, the key header, et cetera. Will that be addressed in Drupal 8? We had made improvements to the file handling of Drupal 7. But certainly you'll be alerted when that file is uploaded to the page. And absolutely that was a problem that we weren't able to address in Drupal 7. And it's a game of these issues where as you upload an attachment to a web page, the content of the web page changed and in Drupal 7 we didn't have a way to announce to the user that there was a change to the page. Thankfully with Drupal announced we now have a mechanism to go off and to provide that additional context. And we have a consistent standard that we can use to convey that change of information whether a file is added or removed and to make sure that that's clearly announced to screen readers. Absolutely. You mentioned color contrast is a new feature that comes with Drupal 8. Is that a part of the things that come by default or do you need to add them into the story? The color contrast is mostly in how Bartek and 7 are structured. So it's mostly the theme layer. But one of the great things about Drupal is that people look at core and they look at what is being done at core and what is being done in core. So if we've built it in with a slightly different change of the CSS and we've incorporated the color of the red that we've implemented in for the asterisks for example which is managed in Bartek but also in core as well. So those are things that are defined and have sufficient contrast so that if somebody is looking at your website unless somebody says overwritten that in the theme there are things that are going to come out and benefit people but it isn't there's always so much that we can do to influence the core themes or sorry the non-core themes, the contributed themes to adopt the best practices and part of that is setting the example and part of that is making sure that there's clear documentation about what are the best practices and how to evaluate your gradients and your CSS to make sure that the CSS name is actually to make sure that the proper contrast is there. I want to be mindful of time so I'm going to ask you one last question really quick there were a couple of people requesting actual presentations of what the features will look like and while Mike and I had discussed that this is just going to be a little bit more talking about what to look forward to that hopefully when the latest release we can do a demonstration and showcase those features Definitely I'm interested in showcasing individual features and providing, assuming that we've got the technology issues worked out but it's also something where you don't have to wait until Drupal 8 is released there's a functioning version of Drupal that you can run right now of Drupal 8 core and you can evaluate it with a number of other modules as well the webpage simply test.me is a really terrific way to go off into both evaluate where core is at now and how things work and function now for sighted users and for screen reader users and this is being functioning and stable for a couple of years now it's a really valuable resource for testing and evaluating but it also allows you to test patches so often when I'm trying to go off and test a patch I don't even install it in my own local environment most of the time most of the time I simply use simply test.me to evaluate how a patch or a module will work with core if you're an anonymous user you have half an hour to go off to test it and to evaluate different components of it so I really encourage people to look at it themselves and learn how to test what works and doesn't work for their focus groups or for themselves with the droop lake core. That's a really great tip and with that we're at the top of the hour so I just want to thank you Mike again for your knowledge clearly you are very well versed in this subject and I think this is a really fantastic way to make sure that we continue to be inclusive of everyone in our community and in our work so with that I will say thank you and just one last request if you have a couple minutes please take the survey at the end of the webcast Mike has a couple questions.