 So, everyone here, I assume, is here for the accessibility talk and how to go off and make your Drupal 8 site more, or how and why Drupal 8 makes your site more accessible, and how it makes it easier. And so, if anyone's not looking forward to a talk on accessibility, then, well, yeah, this is the room for that. So, we'll continue. My name is Mike Gifford. I'm the president of Open Concept Consulting, and also the Drupal 8 Core Maintainer. I've been spearheading Drupal accessibility issues in Drupal now since about 2008, 2009. And it's been a really interesting experience working through the work of, work with the Drupal community and working with people outside of the Drupal community as well to make this project as accessible as we can make it. So, first of all, a couple things, how many people here know what Section 508 is? Excellent. I thought so. This is, you know, in the U.S. after all. Now, Section 508 is, does anyone know when Section 508 was written? When it became law? 1997. Can you remember what the web was like in 1997? Yeah, okay. So, it's, there have been a lot of changes since then. And unfortunately, Section 508 hasn't been able to keep up with that. But there's a legislation that, or not a legislation, there's a set of guidelines that the World Wide Web Consortium has put out called WCAG or the Web Content Accessibility Guidelines. They're right now on WCAG 2.0. So, everyone heard of WCAG? A few less people, but, you know, it's still something that most people know about. WCAG is a really great step forward in a lot of ways because it's based on principles instead of on specific technology. So, the principles that it's built on are being perceivable, operable, understandable and robust. So, they knew that the technology and the framework was going to change. So, they wanted to be able to take a step up and look at what is it that people are trying to do with the technology instead of address that specific technology itself. So, it's a great framework. It was released in 2010, sorry, yeah, in December of 2010. And there's been a lot of technology that's changed since December of 2010. So, you can find that there's movement within the World Wide Web Consortium to try and update and change the World Wide Web, that standard set. I also wanted to talk about PWD or People with Disabilities. When people think about web accessibility, generally they think about people who are blind, which is an obvious extreme use case. And there's people, that's a really important one. And people who use screen readers and other assistive technology, it's a really difficult challenge to try and deal with that particular disability. But there are a lot of other disabilities that are affected by accessibility, by changes in the technology in the web. So, for example, you have people with low vision, people who are color blind, people who have issues with motor problems, whether it's just having tremors or not having fine motor control. There's also cognitive learning disabilities. There are some disabilities that are temporary. For example, if you are injured or on some medication, you may find that you're not able to go off and to have as full functioning as you are when you're not without the injury or without the medication. There's also people who are hard of hearing or people who have epilepsy. There's a huge demographic that's beginning to face a serious, to be of concern for accessibility right now, that doesn't really think about or talk about accessibility. And that's the baby boomer population, because as we get older, we tend to lose our vision, our fine motor controls, it diminishes. And if we're lucky enough to live a very long time, we're not going to have the same level of abilities as we do right now. So, just trying to go off and think about people with disabilities as being more than just that one extreme use case. There's so many different people who use so many different kinds of technology to interact with the web. So, there's people who don't use eye trackers or people who use sip and puff mechanisms to be able to navigate the web. People who are using various different combinations of assistive technology in order to navigate through the web. How many people here have ever gone off and spent like a couple hours navigating without their mouths? It's a real challenge to try and spend any time navigating without a mouth either on the web or through your desktop. It certainly is possible to do, but it's not always that easy to make that happen. But it's a great learning experience to go off and make that jump. So, in terms of the history of the web and why accessibility is important, we can go back and look at Tim Berners-Lee and his vision of the web was one that was going to be available universally and to make sure that the web was something that was going to be available forever. And that's where the real true power comes in. And unfortunately, I think that the web development community in general has forgotten that element and we've sort of rushed ahead because of market forces or because of just human nature for the latest shiny, you know, whatever the shiny object is that we've been running for. And at the moment, there's a lot of excitement about headless Drupal. And headless Drupal is really cool. I don't argue with headless Drupal being really cool, but it does introduce a whole series of other accessibility problems and unknowns because we know how it works and what the challenges are with HTML templates. We don't really know what all the challenges are going to be with a headless Drupal implementation. There aren't that many examples of very accessible headless implementations. So, what makes accessibility a hard issue? So, on the right, I've got a photo of an old friend of mine, Alan Shane, who's my disability mentor, and he's done more work with disability, the disability rights movement than anyone else that I know in trying to raise awareness of the rights and responsibilities of caring for people with disabilities in our society. He's going to be getting himself an eye tracker pretty soon, but back at the beginning of Drupal 7, I went off and videotaped him going off and tabbing through the Drupal 6, Drupal 7 implementation and just how difficult and painful it was to sort of tab through all of the links in the menu structure. You may not have noticed this, but since Drupal 7, we've had a skip links function built into the course that if you're tabbing through the page, you can jump all those menu links and go down to the main content. It's really quite useful for people who primarily navigate by the keyboard, and there's more that we can do with that, but it's a good step in the direction to help people who use the keyboard for navigation. So, on the Internet, everything is in flux, and there's changes that are happening with the browsers, with the sites, the expectations and design change. Is a flat design still in? Does anyone know if that's still a thing? The trends go quite rapidly in the web development community, and in order to keep up with it, there's the technology changes. Every time you're retheming your website, there are implications for accessibility. Every time you use a new framework, every time you are upgrading from different versions of your software, there are accessibility implications throughout that. We also have to look at user needs. Often people don't have just one disability. Sometimes people have multiple disabilities. Often people are using the assistive technology in ways that we didn't plan or didn't expect, or that the developers didn't actually have in mind when they had built that application. There's also a lot of devices that are in use. How many people here have an Android device that they use? What about iPhone? What about everything else? A couple of people have some other kind of phone. There aren't that many people who have some other device, but if you've got a Firefox phone or whatever else, like an old flip phone, there's only so much you can do with the older phones, but there are versions of operating systems for smartphones that are not the standard iPhone and Android devices. Even within Android, there's a lot of variation within that, so you're not just dealing with one particular application with one particular challenge. How many people here think they have a screen reader on them right now? Anyone who put up their hand about having an Android or an iPhone device also has a screen reader. Android comes with talk back built-in and iPhone. Every Apple device comes with voice over built-in, so if you ever try to see what a screen reader looks like or how it works, if you've got an Apple device, you can easily find out how a screen reader works and just enable it through the interface. The other challenge with assistive technology is that we're really at the stage where the browsers were back in the early 90s. There's no standardization of how the assistive technology works, so you could find that it works for NVDA for some people, but it doesn't work for JAWS. There's no consistency around how these tools are implemented. There are some best practices, and JAWS has been the leader in the community for a long period of time, so a lot of people like NVDA is trying to emulate the patterns of JAWS, but voice over and ChromeVox have a very different way of approaching the implementation of their screen readers, so you can't assume that just because it works in one screen reader that it'll work in others. It's a good bet to try it in one. You don't need to necessarily try it in all screen readers, but you can't know that it's going to work in all of them. Of course, all of these assistive technology devices get updated fairly regularly, so there are multiple versions of the software being used to access your website, as not everyone's using the latest version of the code. The other things that have changed, since Drupal 7, a lot of stuff has changed. HTML5 wasn't really an option in Drupal 7. It wasn't finalized until after Drupal 7 was released. The WIA area, which is the Web Accessibility Initiatives Accessible Rich Internet Applications, which I'll be talking about later, area was also released after Drupal 7. We added a little bit of area within Drupal 7. If you look at the install process for Drupal 7, there are some elements that are... We've used a little bit of area in that, but we've used it quite extensively in Drupal 8, and not just in the main library, but also in the... A lot of the libraries that we've included, whether it's Seeky Hedder or some of the other... The libraries we brought in have area included within that. So the last thing that the list of new elements that have been added is ATAG, which is the Authoring Tools Accessibility Guideline. Has anyone heard of ATAG? So ATAG is a great standard, not just because it was designed primarily in Canada, although that really does help. But it's also great because it's looking at one of the main problems that we have with content or with accessible websites. You may be able to go off and create a really accessible framework for your users to go off and create content, but as soon as they start putting in their content, they're copying and pasting it from Word or doing whatever else, and it breaks the accessibility you've spent months trying to build into the product. But ATAG is really an effort to try and make it easier for content authors to produce good content. We also have other things that weren't really considered when we were looking at Drupal 7. How many people have really enjoyed the graphics that are included in the new iPhone and a lot of new devices, like parallax effects? Like the ability of the device to seem like it's moving and have that three-dimensional effect? I think it's pretty cool. It makes some people sick. The visually-induced motion sickness, it wasn't something that we were aware of beforehand, and we still don't really know how to test for that and how to address this, but VIMS is an issue that we need to try and address, and I think that there are going to be approaches for dealing with that, so you can turn off those animation effects as you're moving through the site. We've also looked a little bit at dragging NaturallySpeaking users. So there's dragging NaturallySpeaking and Windows Speech Recognition. Those are two tools that people who have mobility challenges tend to use if they're trying to navigate the web by voice. And I don't really quite understand how... It is an interesting thing to think that you can do that. Click in the top-right corner and you can tell your computer verbally how to go off and to navigate through the web. But there are ways to do this, and in fact, the number of people who use voice control in order to navigate the web is probably higher than the people who use screen-reading tools. So if you're looking at a community that could really benefit from having some more accessibility work done on it, the dragging NaturallySpeaking community is certainly one that I think could be quite useful. The other thing that I wanted to talk with you was form errors. In Drupal 7, we hadn't really set up a way for people if they had entered in a web form and hit submit and there was an error in the form. We didn't really deal with that all that well. We didn't do much to go off and to actually address the concerns of WCAG because modifying the forms API it's a lot of work and we didn't quite get to that in Drupal 7. In Drupal 8, we made some suggestions and we've been working through that and we did get it into core and I'll talk a bit more about that later but we weren't able to go off and to get into Drupal 7 and we've almost got it. It's an experimental module in Drupal 8 so definitely we'll want to have people look at that in the future. The most noticeable thing I think that people are going to look at when they're seeing Drupal 8 though for the first time is we've looked at CSS gradients and we realized that the way that we were assessing the color contrast on CSS gradients wasn't done properly and once we did the proper evaluation with another tool we realized that we had to go off and make the dark blue background darker so that there was going to be sufficient contrast. Now I want to go off and talk briefly here about the importance of defaults because in Dries mentioned in his keynote the number of Drupal website or a website that he ran into that was this default Bartek and I don't know if it had changed the blue background using the color module but there's a lot of websites out there that haven't bothered to even change the background of the blue to something else. Maybe they've changed the logo but all of those websites because they're just using the default stock install have an accessibility problem with that for people with low vision because they just don't have sufficient contrast. So by making the background darker we're helping possibly thousands of sites go and be more accessible by default. In preparing the Drupalcon presentation I decided to use the slides that were presented by the association and I did a quick review of the accessibility of the slides and the colors didn't match, didn't meet WKX contrast requirements either so I used a tool called Tangaroo to go off and to pick a color that was close to the mustard yellow that they had recommended and pick a slightly darker brown as part of that but these are subtle differences I don't know that anyone in the Drupal association would necessarily pick that out and understand that but for any of the organizations that are using this slide deck they're going to repeat the same problem if you're having something that's being replicated a lot of thousands of times potentially because there's not just the presentations but there's also all of the printed material if you don't do that evaluation of your style guide you can find yourself in a real pickle down the line if you haven't considered these things up front and unfortunately not all accessibility challenges are as easy as this to see and pick out Here's an example of you can see the title the text hard is not accessible it doesn't meet WKX 2.0 AA requirements but the text C is accessible so that has enough contrast and it's not much of a difference but it's a little bit of a difference often people get into challenges by adding background images so in this case I've thrown a background image behind the text there and I wanted to verify that this does actually meet WK requirements and it does there's sufficient contrast between the gray and the black but it would be really easy to go off and just make the logo or the watermark that I put in the background just a little bit darker, a little bit more visible but would also reduce the contrast enough that would present problems for people moving forward so most of the changes that we've made in Drupal 8 are semantic they're in the code base, they're tied to HTML5 an area and they're things that most people probably aren't going to see unless you're using an assistive technology tool that's taking advantage of it we're also many of the changes that we've made in Drupal 8 are incremental changes so there's hundreds of thousands of websites that are running Drupal 7 we've been able to take the websites and the feedback that we've gotten from a vast community of users and learn from that community and find ways to advance Drupal and make Drupal even more accessible and we're working to try and prioritize the accessibility issues within the issue queue as much as we can but also there's a lot of groups who have prioritized accessibility in their own function who have chosen Drupal as a platform so anyone here from the UK? Oh two couple people so you'll know who the RNIB is everyone here in the US will probably know who the NFB is AbilityNet is a UK organization like the RNIB those top three are all organizations that are using Drupal 7 and work with primarily the blind community but not exclusively AMI is a Canadian based organization and they've just recently put out a Drupal 8 implementation which was great and there's also the Federation de Avocles du France my French should be way better than that and I apologize the very first accessibility organization to launch with Drupal 8 was a French organization and I think the folks at Happy Co-op went off and put that out I wanted to highlight on the bottom right the Broadcast Accessibility Fund which is one of our clients one thing we did there that was fairly unique was we set up a bilingual website with sign language as well so there's videos associated with each of the pages and all of the content is translated into the American Sign Language as well as the LSQ with the lang design du Québec but we've done a lot of work accessibility has a lot of challenges and a lot of complexity but the goal of this presentation was to try and make it easy and so here's a picture of my cat she's 20 years old her eyesight is not as good she has trouble walking she's quite the sad thing but I had to throw in a picture of a cat for the internet so if you start with good defaults then your website is going to be more accessible and Drupal 7 had in Drupal 6 a real commitment to standard code development or web standards we've also built on work in Drupal 7 to improve the templates and so some parts of them have been rewritten but have been tested to see that those rewritten parts are able to go off and still meet the accessibility requirements that they met in Drupal 7 I want to highlight the importance of a transparent issue queue and that also really does help with accessibility issues because you can do a search and Google about an accessibility problem with the Drupal website and you'll probably land on an item in the issue queue that can highlight the concerns you might have and maybe there's a patch that will address it maybe there's a patch that's waiting to be RTBC that will help get into core maybe you can identify that but having that transparent issue queue allows people to understand if that issue is already there and verify that there's movement on the project for that the other thing is that there's a culture of accessibility that has grown into the accessibility there's grown into Drupal so this is the third accessibility talk the second of three accessibility talks here at Drupal Con there are often issues that are identified as having accessibility issues and are fixed before I even see them there's a group of people who are involved in core who are very aware of this issue and who take this issue very seriously and the culture is one that we understand as a community the importance of accessibility and that's a really important element there's also a lot of times where we've looked for best practices and sometimes we haven't been able to find best practices in the Drupal community so we've had to actually create those best practices in order to go up and to build Drupal 7 and Drupal 8 and hopefully we'll see other organizations beginning to follow us I think the WordPress community is catching up quickly and they certainly are looking at the work that we're doing and finding ways to emulate and to improve on what we're doing and there's certainly other open source projects that can benefit from the work that Drupal has been doing for all these years so HTML5 is another big improvement with Drupal 8 and one of the huge things that... Yes, HTML5 is going to be better for SEO it's going to be better for mobile devices it's definitely more future compatible but most of that is because it's building in more semantics into the code so you have elements in your HTML5 like the header element or the footer element or the aside or the main that allow you to go off and to divvy up your content into different regions to allow it to get to have more context and meaning so that whether you're a machine or whether you're a person using a screen reader you can understand the context with which that sentence or that paragraph is sitting within there's also form elements like the email, phone, URL and there's a number of HTML5 elements that have been added to ensure that you can validate the inputs from users and to do that in an accessible way as well In terms of one of the biggest changes that we've added in Drupal 8 is the details and summary elements which in Drupal 6 and earlier when you were to expand or collapse a web form it was using field sets to do this field sets were a great solution before HTML5 but assistive technology doesn't work very well at all for nested field sets so if you have more than one field set working within the site you can't, assistive technology doesn't know how to deal with that particularly well so we weren't able to go off and use field sets to link together input types like the date input type or the, if there's a phone number input type we should be able to do that but we weren't able to make that semantic relationship between the fields in Drupal 7 because of this problem with nested field sets we're able to do that now and unfortunately Drupal had to lead the lead the march on detail and summary elements I think Firefox is going to have detail and summary elements fully supported in the next release in Firefox 49 but it certainly isn't something that's enabled by default in that browser so I mentioned area earlier and I want to talk a bit more about this the little graphic here is from Carl Groves and I don't actually want you to area all the things there was a study recently that evaluated a bunch of websites and area has been implemented in many cases so poorly that Steve Faulkner who's an accessibility guru I think he's in the UK said that in his evaluation if you eliminated the area from the website that you would make the web pages more accessible, not less accessible so area is a great tool to extend HTML in places where it's necessary but I think a lot of times developers are using it as a shortcut so instead of using proper HTML to semantically create information like buttons they'll just go off and take any tag and just say well we'll just define this as a button using area which theoretically kind of would work except that's not how assistive technology devices use it it's not something you can rely on if you're looking at barriers to users so definitely use HTML5 first don't use if the semantics is defined by the HTML5 don't also repeat that with area and there may be a few places in core where we need to go off and look through and eliminate that because I think that we did implement some of these changes with both area and the HTML5 descriptions but it's something that in general we've got a pattern that you can work with and that people can use as a reference so it will make it easier when you're doing your implementations area is quite complicated I don't want to spend too much time on area because we don't have a whole lot of time but there are landmark roles which you'll be able to see within your templates there are states, things like area hidden and area checked which are on and off there are properties, so things that define relationships if you look at form elements you have the label, you have the input form and you have a description and the description is tied to the label by a property, an area labeled by a property there's also area live elements which are really quite useful for content that changes so much of the modern web is about pages that get modified on the fly so you've got some Ajax in there that updates the page as you've entered some content or maybe a field appears because you've entered that you're in the states instead of Canada so the postal code changes assistive technology doesn't know that that is happening unless you tell it that the page has changed and area live is the right now the best technique to go off and inform users that that page has changed and there's area live, area relevant, area atomic, area busy and it's a lot that can be done well for screen reader users if it's done properly there are some advantages also for, right now area is largely benefitting people who use screen readers aren't that many other devices that are using this but that is, whoops, that had to happen but more and more there's an ability to often hang JavaScript elements onto the area and have it be useful for more than just the screen reader users so HTML5 boilerplate, how many people are familiar with that? so this was quite common when Drupal came out and they came up with a solution for CSS, the problem with CSS display none that was quite similar to what we did with Drupal.org we've done it too close at the same time and so we weren't able to go off and adopt that same nomenclature then do people know what the problem is with the CSS display none? so the problem is that if you use CSS display none to hide content on your page the screen reader interprets that literally so it might be hidden from the page for sighted users which is fine but it's also hidden for screen reader users so if you have headings in core which we have a lot of headings in core you may not want to see that you may not want to have all your users have that clutter on your screen but it's important for screen reader users and if you're not using the, in Drupal 7, if you're not using the area sorry, element invisible to hide that content then you're going to, if you're using display none to hide that heading information then it's not going to be useful for people with disabilities so we've, in Drupal 8, tried to go off and take on a stance of proudly build elsewhere we wanted to learn from other projects and adopt other projects and so we took the language that was implemented by the HTML5 boilerplate and implemented that in core so if you've got any modules or themes that you're using you should look at upgrading those from element invisible and element hidden to hidden, visibly hidden, and visibly hidden on focus and the other thing is that these things it's also important because how these assistive technologies address things like on, it changes over time so right now there's an existing bug to modify what we've done in Drupal 8 because voiceover users do not, there's a bug with how this, the CSS classes work with voiceover users fortunately for, there's one place to change those classes one place to update them and there's a patch that just needs to be reviewed and updated in order to go off and end to, in order to fix that for future sites so this is a logo on the right of the accessible icon initiative there's a movement in the disability rights community to not show people with disabilities as passive victims but to see the more active members of society and so I wanted to highlight that because it's a cool logo but also to highlight some of the centralized things that we've added to Drupal and Drupal 8 to help make it easier for your accessibility efforts the first one is that we have, we've added a JavaScript library called Drupal Announce which will, if you're encapsulating, if there's text that changes based on using Ajax you can now have a simple, consistent way to go off and to call area live and to make sure that you have an accessible implementation to alert the user that that page is being updated there's also for keyboard only users the Drupal tabbing manager they're in complex web, I guess, in complex web interfaces it's not uncommon to get stuck in a keyboard trap where you're tabbing through the interface and then suddenly you get stuck in a loop somewhere that you can't break out of what the tabbing manager does is it allows the developers to control the flow of the user's focus through the page and ideally it will be going from logical progression as you're browsing the site so not most keyboard only users have their site and so you need to try and look at where are they looking and how are they navigating the site where should they expect the focus for the page to be so we've also created some good defaults and we required alt text in Drupal 8 which is a pretty big thing I don't think there's any other CMS that is requiring alt text by default at the moment now this can be disabled and it was actually quite controversial in the accessibility community for a while because it's not always appropriate to use alt text there are some times where you don't want to have images associated with the text if it's purely a decorative element if you're using that image more than once if you have like five hearts in a row you don't want to have to say heart, heart, heart, heart there are times when you want it to be blank but for the most part you want to have users go off and to make it as difficult to enter in the alt text as it is to skip it so that they're more likely to go off and to take the time to fill in the alt text and to write heart or whatever within the interface we've also made some improvements to views and tables and I wanted to talk about the inline form errors as well just briefly this is a game I mentioned earlier but it's huge in terms of dealing with interactive forms I would encourage people to try and enable the inline form errors by default because the changes are quite minor I can talk to you about what the problems are and I agree that as it is right now it shouldn't be enabled by default in core but it's in core as an experimental module and it shouldn't break anything and most of your users will not notice the changes and it won't be a problem for most websites but it is going to be a problem for some and it wasn't quite stable and strong enough to be enabled by default in core hopefully that's something we can address in Drupal 8.2 or 8.3 the inline form errors allows you to have links that jump from the description to the text where you would actually change the form item it has descriptions that are defined by more than just color there's an icon as well as the color so it addresses people who are colorblind there's an area described by in the error forms that you have the additional semantics there I wanted to talk also about the big deals in Drupal we all know Dries although Jam's not wearing his red suit you can also see that he's there but Vincentio Robano is on the right and he has in his final year of high school in the summer before he began university he contributed more to Drupal core than any government like all governments in the world and all accessibility organizations to accessibility so as one person he went off and tested and evaluated and identified problems more than all of these other institutions that should be aware of these problems and should be contributing to core and helping to push this forward and so far aren't the CK editor is a big improvement and that was brought into core and it was really a reciprocal process because not only was core improved by bringing in CK editor as a mature, whizzy-wick editor but also we were able to push back on CK editor and see that CK editor inherited the best practices that they improved some of their interface to adopt better practices we also had the language of parts which for multi-legal websites was quite important if your web page is defined to be in French and you've got an English phrase within that the screen reader isn't going to know what to do with the English phrase it will read the page header it'll start reading whatever the page header's language is defined in and then when it gets down to the string that is in the other language it will pronounce it very badly in whatever language that is the views UI was another big one in Drupal 7 it was quite accessible for most people who were managing the... were trying to administer and edit the website Carolyn from Berkeley is here who's improved a lot of Panopoli and C tools and panels with work with the university there which is amazing but the other area that people are running into was views and the accessibility of views but bringing views into core meant that we had to make that user interface accessible it had to be raised up to WK 2.0 AA and it's one of the more powerful features of Drupal to encourage the blind community to use Drupal and then say oh well you can't use the most powerful contributed modules it really wasn't all that fair so that's been improved and we've added some other things like caption and summaries is something that you can define for views tables as part of core as well and ATAG ATAG has touched on it briefly but there's two components to ATAG the first one is making sure the user interface itself is accessible and we've done a good job of that in Drupal 7 the back end is pretty accessible but it's also trying to ensure that when users are creating content that they're reminded of accessibility and are encouraged to go off and to to make better choices about their content when they're creating the content so there are things like required help text or there's help text to explain the accessibility implications of some of the things we've added into core there's also I think 8.1 we brought in a spell check screen readers are great but they aren't really good at pronouncing misspelled words so if you can add a spell checker into your whizzy way editor you can address some of those problems and hopefully solve some confusion for the blind community and for that matter other people who are using screen readers to go off and read content to them the accessibility does require constant vigilance it's not something, it's a journey not a destination the WCAG comes with three standards there's A, AA and AAA if you ever get an RFP asking for a AAA website don't ever bother replying it's not possible if you're using any complex website maybe for one or two pages a really simple site you can make a AAA compliant but AAA is really something that you want to strive for things like to say if you want to beat the checklist and exceed that and try and find ways to go off and to remove as many barriers as possible how do you do that and AAA gives you some great ideas to make that possible it's important to remember that legislation is changing and right now any organization that is currently required to meet section 508 requirements is probably going to have to be learning the WCAG 2.0 requirements pretty quickly because that's what the Department of Justice is holding organizations to and there's an ecosystem of technology that is changing all the time so in the last couple years we've been all excited about mobile devices and mobile first development but in five years time who knows what we're going to be struggling for and where the technology is going to be are we looking at embedded devices in ourselves or what kind of challenges are we going to be trying to solve to keep up with the internet there's also personalization so people are there are people who have very different needs so some people need to have high contrast in order to go off and to see the website some people need to have low contrast if you have low vision you want high contrast if you're dyslexic generally you want to have low contrast I had a blind user a while ago who had some site and he navigated the web with some vision but we used a JPEG to make a nice beautiful front page but we couldn't but he wanted to there was too much contrast for him there was too much glaring white content so it gave him a headache when he looked at the screen so we had to change that JPEG into a PNG file so that it would be transparent when he changed his CSS it wouldn't go off and give him a headache when he looked at the site so we need to address accessibility issues by baby steps we can't do it in one giant leap and there's a bunch of tools that I've listed here that you can use and they'll be making these slides available and link them from the website so you can take a look at them but webbing Quail.js the Tanagram contrast finder these are some good open tools not necessarily open source but ones that you don't have to pay for there's also the WK Contrast Checker and the Chrome Contrast Analyzer that are also quite good the I also want to there's a phrase about nothing about us without us and so often people with disabilities are not included in the process and it is important to try and engage people with disabilities in evaluating and looking at your website ultimately they're going to know a lot more than any of these automated tools are it's also useful to go off and engage with third parties and have a third party review the content you've been doing just think about a third party accessibility checker as a just like having an editor for your book it's just somebody to go off and check things that are obvious to make sure you haven't missed anything and to give you a review of how to improve in the future so I have another kitten photo in this case to highlight it's not just free as in beer for open source it's not just free as in speech but it's free as in kittens so if you don't find ways to contribute back to open source projects if you don't find ways to nurture them and to love these projects and to see that you're able to put time, money and resources into them you're not going to get a playful cat when it grows up you're not going to get a ferocious feral feline so think about ways to contribute back to the community and that's it are there any questions? yeah there are some good tools that do work with drop down menus it's just a matter of trying to go off and find a good menu to adopt a lot of them haven't been tested all that well for keyboard only users well no, not using hotkeys like the hotkey idea or access keys they're a great idea except it's really difficult to implement properly there are you basically need to the answer for hotkeys is to allow users to personalize them and to say ok we want to have you know shift alt s to go off to get to the search bar we want to have this combination to jump to something else and there's so many different web pages and so many different languages and for so many different contexts and the assistive technology tools are already using so many of those hotkeys already so you can find you might have a great set of combinations that would work well for you but it doesn't work for JAWS users or it doesn't work for NVDA users or it doesn't work for whoever so it's very personalized on that side in terms of the knowing where you are I mean not knowing where you are on a screen is a huge deal and it's frustrating that often more effort is put into providing CSS to highlight the on focus behavior for links and other elements for keyboard only because there are on hover versus on focus and there's the CSS link project is being used and does identify where CSS isn't matching so if you have hover and not focus or sorry hover but not on focus it'll provide an alert and ask you if this is something that should be addressed with hover as well but it does take testing and evaluation and retraining because people are used to doing it just for the mouse yeah absolutely I mean it's just one way to know where it is and you can look at examples I think the pass yellow group has a nice one where you're tabbing through the interface and every link that it clicks on is provided in super high contrast mode so you can sort of see that link you can see right where you are there's no guessing where you are it's immediate and more sites should be doing that and there's in fact an open issue queue and dribble aid to add that in so it's hard to go from everyone Mike, just wondering about those of us in the room who are tasked with implementing designs where the designer is not that accessibility minded are there good solutions for if you have a low contrast design that looks really cool to someone with 20-20 vision but you're kind of aware that this isn't going to fly correct are there solutions in place other than having an alternative high contrast theme or something like that you can use a high contrast theme but that's not a good pattern you want to be able to have I think the solution is to give your designer a pair of dirty glasses and have them sort of look at it you know what designers are they were the nicest newest glasses they just need to finger and walk away that's right it is a challenging thing with designers and I don't know what is the best way to go off and deal with that except by going up and sometimes even corporate style guides have major problems with them so yeah and let's make it 9 point fonts as well just because 9 point font is just so cool as well it's really cool to see that dribble aid has like the dribble announce on the tabbing manager that any developer can take advantage of in their modular is there anything similar for drag and drop interfaces because I know that there's some like I do a lot on the panels ecosystem and if you're using the panels in place editor then you have this drag and drop which is not keyboard accessible so is there anything in triple aid either in core or in contributing to make either an accessible drag drop or a very easy alternative to it the only thing we've come up with so far is the coding core to disable javascript around that or to disable it right is for the drag and drop for tables and that was done in triple 7 and it's not a great solution and but there's nothing for panels that you can rely on so that only works really well that's like for roadways yeah well, you're at the beginning the shit out of module is keyboard accessible and everything I don't know if they made any planning we keep trying to contribute code as well that we've done to make it more accessible and nobody's really answering us I mean if you're contributing code back and people aren't responding sometimes it's a matter of going off and having more people join on the voice so feel free to reach out to me if we can have a few more people involved in these issues where there's accessibility improvements being proposed or even areas where a bug is identified and you want to go off and address that the more people are involved in looking at an issue the more likely it is to get solved most of the time anyways but in terms of an example of a module that I would recommend I don't have one in particular to point you to that's going to have those issues solved unfortunately the simpler the better and for both usability and accessibility Oh, does Berkeley, you've got one? I think SVG is great especially because you can go off and take it's better for mobile it's like all kinds of you can add titles into the SVG graphics so you can provide that semantic meaning you don't need to have an alt text into the image which is great because sometimes the image gets separated from it but there's also challenges like I still haven't got a good answer on how to do multilingual with SVG because if you've got the text inserted into the SVG you can't necessarily have it available in multiple languages and also the images may change depending on the context so if you're putting the title the description into the title of the SVG file and you're presenting it in multiple different contexts you may want to have various different alt texts available for depending on how you're presenting it yeah, yeah unfortunately you have a quick right in Drupal 7 in Drupal 7 yeah, there are some problems and there's also when you're in Drupal 7 I don't think it tells you when the upload has failed in Drupal 8 it does tell you when the upload has failed but it doesn't tell you when the upload has failed so it needs work I think that the modal dialogues in general are working and that they're I think that that's leveraging the work that was done by jQuery UI and I think that that's tested and worked but again I'd have to know specifically about what assistive technology we're using to navigate that the upload form and where the problems were okay which? for reviewers for your accessible site like you suggested are there any resources for that no that's the biggest challenge we face accessibility features we're not sure if they're actually accessible if they're based on old updated ways there's a huge problem in the way that our society is dealing with accessibility the money is downstream it's on the end site the money isn't at fixing the problems at source if we were looking at how do we there's so many people who want to have an accessible video module or an accessible mega menu or have something that's tested and validated and that they can maintain over time but nobody's putting money in that everyone's putting money in the lawsuits and the work around re-creating the wheel over and over and over again for each individual site so it's a huge challenge and there should be resources that are going into testing and evaluating and engaging with people with disabilities to see that we can make these tools better and more effective for them but yeah, no so thanks, Ying hopefully there'll be a chance to talk more there's another session that's tomorrow morning Helena has a session that's worth going to to look at how to go off and into a number of things but also how to sell accessibility to your clients