 So, my name is Mike Gifford and my talk today is why we should get excited about ATAG 2.0. So, my name is Mike Gifford and I'm the president of Open Concept Consulting, also the Drupal 8 core accessibility maintainer, there's three of us at this point, but I've been spearheading accessibility in the Drupal community since 2008, and also an organizer of Aliyah, which is Ottawa's Accessibility Unconference, and you know, working with Tufa and others to try and build awareness of accessibility here in the Ottawa area, and how many people here from Ottawa? Okay, so everyone who's not from Ottawa, there's also accessibility events that are happening in other cities, Montreal and Toronto, and Quebec City all have accessibility conferences. This is from an accessibility conference that I was able to go to in Quebec City and I went with a bunch of people here in Ottawa, and there's a thriving community of people that are trying to raise awareness about web accessibility issues and how to go off and raise the bar to make it easier for everyone to be able to access the web and to manage that. I'm also the author of a Drupal security guide that's available for free that you can download through our website and have done some work on performance and sustainability as well. So I do hope that most of you have some understanding of accessibility, but I'll try and go off and base on some initial answers, give a bit of a preface to this talk. So first of all, this is David Best, who's an accessibility consultant from Toronto who's done a lot of work with IBM and others, but I wanted to start by going off and letting people know that when people are talking about web accessibility, often they think of the extreme use case of blind users, and blind users are definitely an important extreme category, but they're one of many different types of people with disabilities who are restricted from accessing and leveraging the web, and if you look at all of the people who have challenges with web accessibility, it is between 10 and 20% of the population. So it's a really large portion of the population. If you're compared to things like the amount of times that web developers are worried about, how many people who are using IE 9 or 10 are having trouble with their websites and trying to deal with those sorts of issues? The proportion of people who are restricted in facing barriers to web accessibility is much higher than the people who are worried about legacy browsers, and yet it's much more common for users to get worried about how do we deal with these old browsers and to engage with that, rather than how do we deal with the many people who are keyboard only users who have trouble navigating the web without a mouse? So there's, in terms of people with disabilities to think about, certainly there's the visually impaired, but that includes not just the blind, but people who are low vision and people who are color blind. I'm often baffled because tech is such a mail driven industry, and yet we've got, I think 5 to 10% of the male population has some form of color blindness, and this is an industry that's dominated by men, and we think we'd be able to go off and get that color blindness right, and yet we don't. Oftentimes things are meaningless conveyed entirely with color or issues with red and green being hard coded into the user interfaces in a way which really shouldn't be there. Even this little device here, which is using red and green to indicate different issues. It's like, well, this recorder shouldn't, there are other ways to go off and convey information, and using those colors isn't necessarily the best use of accessibility. There's also people with physical and motor disabilities, so whether you have cerebral palsy or multiple sclerosis, or whether you just injured yourself on a biking and you're wearing a cast and you're trying to go off and tend to use your mouse with your left hand, there's all kinds of ways that people have either various kinds of permanent or temporary disabilities that affect their ability to engage with the internet. One of the more complicated forms of accessibility issues is cognitive and learning disabilities, and this is people who are dealing with things like dyslexia or people who have some form of learning disability or are dyslexic, or for that matter even people who are trying to go off and engage with a website in the second language. So if your first language is English and you're trying to read a French website, you may have trouble doing that, and you may have difficulty going off and understanding how the navigation works and how that works, and hopefully you can just go off and jump back and forth and toggle to the English text, but you can't always do that. There's also, of course, the heart of hearing population or the deaf population, and so much of the web is driven by text, so a lot of people are able to go off and read that information, but there's some really interesting things with the hearing impaired population that a lot of people who are learning sign language, actually sign language is their first language, and English is a second language, and there's a different cultural and linguistic background to people who are hearing impaired, and to realize that people who are hearing impaired actually often have a smaller grammar set than people who have hearing, so even if you're reading text, you might need to go and simplify that and have simpler text to see that you can address a broader base of the population. The baby boomer population is a big one as well, and just dealing with seniors in the aging population, there's a whole range of disabilities that come simply with aging, and I think that that's something that, if you were going to go off and ask a potential client or a government agency, are you willing to write off the baby boomer population? Are you willing to write off that generation of people? Nobody's going to say yes, and yet very few of them are willing to go off and invest in the infrastructure to see that that population is sufficiently supported, and there's things that are different for aging people that need to be considered, but there's a lot of similarities with many people who have other disabilities, and the temporary disabilities are an interesting one too, whether it's you lose your glasses, or you're on some medication that affects you, or you're just feeling, not feeling particularly well, maybe you've got allergies that day and your eyes are all fuzzy, like there's all kinds of ways that we are not necessarily able to go off and function at our highest possible abilities all the time, so trying to think about that. So the World Wide Web Consortium is an agency that's being looking at ways of increasing standards for the internet in general, and the Web Accessibility Initiative, which is a section of the World Wide Web Consortium, has created a standard called the Web Content Accessibility Guidelines, and the first one I think was in 1998, WK 1.0, the second one was in 2008, OK, for WK 1.0, but 2008 was when the WK 2.0 was released, and WK 2.1 will be released when? Probably March next year. March next year? Between March and, it could be as late as June, but it's not going to be much later. It won't be before the summer. So there's a draft available for... Well, yeah, we have to ask, but the success criterion still, we just finally came up with our consensus on what's going to not give us anything that's beyond what we've already gotten there is not going to be easy. We're looking at 23 right now to be a change, but the drafts are pretty early. So WK is broken down into perceivable, operable, understandable, and robust, and WK 2.1 fits into that framework you can learn more about that in the next session. And this framework is really quite useful, and it's broad, and it's principle-based. One of the things that was an issue with WK 1.0 in Section 508 was that it was based on technology, and moving from a technology-based standard to something that's more future-proof was really quite important. And the web accessibility initiative has developed some interesting ways to try and look at how to build standards that allow for that future-proofing and the use of systems and flexibility between different technologies. So this is a slide from a bof from one of the Drupal coms and looking at Drupal 8 accessibility. And I just wanted to remind people about how influx everything is on the internet. When we were developing Drupal 7, there were things that we couldn't use because HTML5 hadn't been developed. The WAI area had not been developed when we released Drupal 7. We were able to include some of those elements because some of the elements were secure and stable enough, but we couldn't do that much in Drupal 7. We can now in Drupal 8. We're looking a bit about what to do with WK 2.1, but that is something that's only come about very recently. So there's not very much work that's being done on WK 2.1, but we have been able to go off and look at things around this ATAG, which is the Authoring Tool Accessibility Guideline. So because there's so many changes, and some of them are questions of user needs, like again, if you look back at over the history, if we look back over the, you know, going back to 1999, the web then was considerably different than it is now. Now it's essentially a front end for an application, like you're so many of your banking needs, your word processing needs, you're so much of what we do online now through a web browser. It used to be done as an application on the desktop, and now it's being done on your phone. And if we look ahead in 20 years, it'll probably be done through voice, through your phone, through your stereo, through your fridge. The ways of our interacting with the technology and organizing that information is rapidly changing. So, you know, this was a big innovation 10 years ago, going off and having your first smartphone. But this is something that's normalized now, not that everyone's doing it well, but it's a normalized piece of the technology. And a lot of people are wondering what the next step is going to be, whether it's artificial intelligence or whether it's time to other voice control and whether that's that. You know, what are the pieces you're going to be building your website to, what's going to be the next sort of technology we're going to have to run across with that. One of the challenges with accessibility is that there's a lot of conflicting information, because there are things that have been the case and have been issues that have, you know, five years ago, the best practice was X. And somebody wrote a great blog post describing how this is a good pattern and this is how it should be set up. Well, you know, the browsers change on a regular basis and the assistive technology changes. And, you know, something that may have been a best practice five years ago is not necessarily going to be a best practice today. And so, trying to make sure that you're testing and reevaluating and looking at the current technology to see how well does that fit the needs of your user today and are the patterns you set up going to be something that are going to support the technologies that people are using today. That's a, it's a real challenge. And so, there's elements that we've built into Drupal 7 and Drupal 8 that have helped with that. So, one of the basic problem, or one of the many problems around accessibility that we tried to address in Drupal is CSS displaying none. So, this is a way of just hiding text. And we have in Drupal 7 and 8 a centralized class to go off and to deal with, how to deal with text that's visible only to screen readers, text that's visible to everyone, and text that's visible only on focus. And those are really interesting distinctions, but browsers aren't necessarily going to go off and deal with those at the same way all the time. So, we need to have the ability to go off and update those sets of CSS classes to see that there's a more accessible way to go off and move this forward. There, let's see. There's also people are, the standards themselves are changing. You know, I mentioned that HTML5 was something we couldn't do in Drupal 7. There are, you know, HTML5 continues to evolve and there's tools like can I use that are evaluating which classes that you can implement. There are things that the Drupal community built into Drupal 8 that were quite early on like the use of detail and summary elements were part of the HTML5 spec, but the browsers didn't support that properly for a long time. So, we had a, you know, hacked trying to backport that with JavaScript, but there was, just because it's in the spec doesn't mean it's supported by the browsers and it doesn't mean that it's supported by the assistive technology either. So, there's a, you know, so much of the challenges of accessibility is realizing that so much of it is, it's very much like the browser wars of the early 90s where there aren't necessarily agreed to approaches to dealing with different technology. VoiceOver is going to do it one way, JAWS is going to do it another and NVDA is going to try and go off and work with the community of users to try and find an open source solution that allows for a, for something that works for most people, but it's, you know, that's at least one space where there's an opportunity for engagement, but when you're dealing with proprietary vendors like Freedom Scientific and Apple, you're not going to have the openness and transparency that you do in an open source community. So, yeah, perpetual vigilance is definitely required. So, this is a slide with Danny Boudreau who's presenting at Carleton at some accessibility event a while back. I can't figure which one this was at, but he was presenting about looking at the testing process and the first step of testing for accessibility is doing automated testing. You can't see that because it's crossed out of the screen. The second one is doing sort of manual testing just trying to tab through the website and seeing if you can identify problems by tabbing it through it. And only when you've done those first two steps should you go off and actually test it with a screen reader. Often people go in and developers will go off and try to test it with a screen reader and they don't know what they're looking for and don't know how it's working. And it's really, you know, for most developers, if you can handle steps one and two, that's a good place to go off and to end off. And don't assume that just because you've used Chrome Vox or VoiceOver that something is accessible, that there's a lot of assumptions that you come in as a sighted developer that are problematic when you're using a screen reader. But there's a lot of ways to learn about accessibility. It's a complex field. It's not something that's a simple check box that you can go off and say, yep, it's accessible. Because even if you've gone and spent a lot of time and effort and brought involved experts in evaluating your site's accessibility, as soon as you wait a couple months, if you add content or if the browsers are updated and there's changes that happen to the browsers or the assistive technology, things that are accessible once may not be accessible in a few months time. So you need to be looking always at how to go off and end to a fine best practices. It is very much a, there's a lot of similarities to security and performance in that these are things that need constant maintenance. And you're not, this isn't a check box, you can say it's done. That's never going to happen. Even just to keep up with your legal expectations of WK 2.0 AA, which is the standard for government agencies here and for large organizations in Ontario, under the AODA, there's requirements here. And in the US, in fact, if you have any American clients, Section 508 and the Americans with a Disability Act are now both standardizing on the WK 2.0 standard. So you may have a client that is facing a legal lawsuit in the United States because their website does not meet the WK 2.0 standards. So it takes a lot of time to go off and learn how these systems work and be able to optimize them for accessibility. And there's some great resources out there. And I definitely encourage people to learn as much as they can and to keep pushing themselves to try and find out what are some approaches to make your websites more accessible. There are some really great tools to help look at that. I do recommend people use the Wave toolbar by WebAIM. That's a really simple one. Tenon is another one that Tenon.io where it provides a quick way to go off and do an accessibility review of your website. And this only catches, the automated tools only catch about 20% of the accessibility problems on a website. So that's not much, but at least if you've caught those 20%, you're ahead of where you were before. So involving automated tools to check to see that you've got alt tags on the images to see that you've got heading structured in a way that allows people to go up and to understand the structure of your content. That's all very useful. And using these automated tools are it doesn't take somebody with neither of them are particularly technical. Tenon is more technical and more geared towards that. But the Wave toolbar can be used by managers, by content editors, by anyone, because you can see little red boxes and say, Oh yeah, I understand red is bad. And it's a simple way to go off and say, Is this an issue that we should be looking at or not? Not that it's authoritative, but it's a way to go off and identify some of the broader issues. But you know, yeah, when you when you have built a number of accessible content management systems, one of the challenges is you hand it over to the client. And the client starts entering entering content. And as soon as they start entering content, the accessibility goes downhill. And it goes downhill because your content editors are not technical. They have not attempted to read the WK 2.0 double a step specs, and they're not going to because incredibly dreary to go off and understand how the WK specs are. They're not written in an understandable user friendly manner, certainly not for content editors, barely for web developers, and something that that it's not particularly structured in a way that that invites people in to go off and to to learn the best practices in a step by step method. So how do we get get beyond this problem of building this lovely website, making it accessible, handing it over to the content editors, and having the the the technology or having the the the content slowly get worse and worse as content editors add add information and skip the alt text and and are, you know, messing with the heading structure or doing other elements like adding multiple font tags that are screwing with the color, you know, there's a lot of stuff that content editors can do within most content management systems to be able to to mess up the accessibility, not that they're trying to, but but it does often happen. So this is Catherine Lynch presenting at Drupalcon. And it was, you know, think that the the wanted to go off and remind people about how how all systems affect their users and and content management systems are a real step ahead of how people used to develop websites, because it used to be that either you hand coded it, or you use front page or Dreamweaver, or some other tool and whatever tool you're using, it's shaping your what are the abilities of what you can do and how you can and what are the options that are available to you. Dreamweaver gave you a lot of options in terms of design and customer customization. But it also made it so that it was you could have you could very easily go off and and screw up your website by by having different navigation elements and different pages and and made it so much easier for people to go off and and to to to make some mistakes in that it gave so much so much control over to the user where they could delve into the design and and often overlook the content. Content management systems tend to focus people and that's that's great. And it's it limits their both their design options as well as their the security risks. Most content management systems don't allow people to insert JavaScript, or at least it restricts the access that people can have access to add JavaScript. And sometimes, you know, content management systems will limit the use of tags that are available within the the body of the site as well again as a way of controlling the kinds of damage that content editors can create. It also focuses the content editor on creating the content and the text and making sure that the content is being produced in a predictable manner. I like to try and think about accessibility in terms of filters, because ultimately what content authors want is they want to be able to convey meaning to an end user. And there are at the more steps, there are more barriers that are between the the content author and the editor, the editor, the more information is lost. So there's what the the author means. There's what the CMS allows. There's what happens after an accessibility review. And sometimes you're going to find find things that are excluded or things need to be modified after an accessibility review. There's also what the browsers can render. And then what the assistive technology reads. And then finally what the author or the user understands. And, you know, if you don't have a disability, you've got a much more direct way to go off and to to access to convey information from the author to the to the user. But but when you're using other systems and other technologies, it's it's it's like a one of those those puzzles that you you have and you're trying to go off and get the the the the loop out of the the chain of of what are those like little mind puzzle games that you sort of you know, fiddle with with bits of technology, and you have to get it all lined up in order to go off and to to to make sure that you've you've conveyed the meaning properly between from one to the other. And, you know, the content management system can help guide the process and make sure that there's more more information being effectively conveyed over to the to the user itself. And no matter abilities that the end user has. So this is at triple con Portland. And the in the middle, there's is with second Vincent, Bench, Vincenzo Robano, who has has as an individual contributed more to the the Drupal eight accessibility than almost all government and educational institutions in the world combined. Not quite, but he did that in like the summer between the summer before he started university. So it's like, you know, there's a there's a lot of organizations that that have have have not built in the habit of contributing back contributing upstream. Fortunately, we do have some people like Liam here who've contributed from the University of Waterloo and David who's contributed at the access at the Drupal sprint for Drupal eight and Montreal a little while ago. We do have some some people who've contributed back and that's that's great. But but it's, you know, wanted to go off and highlight the importance of contributing back to the community. So Drupal core is quite accessible out of the box. And that's that's great. And we've you can you can inherit a lot of accessibility improvements with with that. And if you start with an open source system with good accessibility will certainly help. If you have a third party review your website that is also useful. Even if we, you know, we do a lot of work on web accessibility and and but but it's sort of I think having a third party is quite useful because because often it's like, if you're writing a book, you want to go off and hire somebody to be an editor. Even if you're an excellent writer, you're going to hire an editor because you're going to have a third party review your content and see that it makes sense. And this is very much how people should be looking at at the web as well. You want to hire somebody or have somebody on staff who really understands web accessibility. But you also want to have a third party perspective in there to go off and have a review that says this is how it should be done and this is how how should how should be organized. I also definitely encourage that people look at at getting feedback from people with disabilities because that's something again that's this often overlooked even asking for it in your on your accessibility page. And if you identify any problems, if there's anything that we've missed, please let us know. Having that that open acknowledgement of ways that that you're looking to go off and improve your website's accessibility. Nothing is going to be 100% accessible. So how do we try and consider this as a journey and not a destination? It's not a failure if you aren't 100% accessible. It's just the nature of the beast. But we need to try and look at at what editors can do and how do we limit the kinds of mistakes? How do we put training wheels on the editing opportunities so that people are able to to make better better decisions about the content that they're they're creating. So the World Wide Web Consortium has this 8AG 2.0 standard and it's broken down well first of all it's a it's built by in in Ontario. A lot of this was pioneered at OCAD in Toronto and Jan and I forgot her name Utah were the two people who did did mostly work on flashing out of this policy and and it's broken into two parts. So the first part is Drupal actually does really well because we've actually looked at trying to see that both the front end and the back end are meeting the same guidelines of WK 2.0 AA and we're one of the few content management systems in the world that have really said we need to do this and this is something that's important for everyone we want to be able to have you know developers who are accessible like Everett Zufeld we want to be able to have have people who are content editors we realize that when you're building a content management system often you're going to have engagements and you're going to want to have community be involved and and and interact with each other so how do you you know some of those admin design patterns are going to be replicated for other uses and for for general users so you need to have a system that's open enough to be able to allow for interaction and so so you know a tag the part is is it just trying to make sure that the the back end is accessible and not that we're perfect at this but we've done quite a lot to try and see that that the that content authors and administrators can engage with the back end to see that that those and have accessible patterns for for things with with the back end and part B is about ensuring that the authoring tool helps authors produce successful content so this is this is the area that we've really made some real efforts to try and incorporate into to Drupal 8 and there's still work that's being done to to integrate this into to push this forward but the the work we've been doing around around a tag is is is trying to to see that that we're we're we're we're we're setting it up so that that we have that guidance and one of the things that we've made the most progress on recently is the is is looking at the the inline form errors and and this is something that has just gotten out of the the experimental module phase it was an experimental module was one of the first two experimental modules in Drupal 8 and it almost got bumped out but it's trying to make sure that when you're entering in a form if there's errors that they're presented in a way that's accessible and that it meets the WK 2.0 requirements but but that's that's now you know built in as as part of core and hopefully in the the future will be something that is enabled by default so that people will will get that experience out of the box and don't don't have to enable it afterwards so the this is a sign of an accessible parking lot an old accessible parking photo and so so I'm now looking at a tag 2.0 part B so there's there's four sections to to part B of a tag one is to make sure that you have a fully automatic process for to produce accessible content and just you know it's trying to go off and see that it's structured in a way that that that as much as possible the system is is inheriting defaults to see that that accessibility is accessible patterns are produced for the end user by default and because Drupal is a highly structured content management system it it's it's easier to do that so we've when you add a block to to a Drupal page there's a heading associated with it you may not see the heading but there's a heading associated with it so users can navigate with that you don't have to think about adding the heading it's not sort of something that that is a an extra thought do you have to sort of think about well how do I make this this block is structured in a way that's that's accessible the content management system says you're creating a block therefore we're going to assume that there's going to be heading associated with that and we're going to add that to the page now that could be visible or invisible but the content the heading itself is going to be there to provide the structure to the website so the WK 2.0 AA B2 with the second sort of point under this is to see that authors are supported in producing accessible content so how do we guide the authors to produce accessible content how do we see that we're able to assist the authors in managing alternative content for the non-text content and how do we see that authors that we assist authors with accessible pre-authoring offering content so an example of assisting authors with with non-textual content are things like alt text on images so in Drupal 8 you now have the option to by default if you try and enter in an image in Drupal 8 you're going to get an error because if you are going to get an error if you don't have alt text so you need to you know there's an error that's that's that's prompting the user to go off and to to enter in alt text when they're entering images it's just harder to forget if Twitter did that every time you were uploading an image to Twitter it'd be really quite interesting you'd have it'd be a considerably more accessible social media platform if there was just that prompt and not that you can't override it but it's a but the defaults are there so that that you are prompted to go off and to fill in a fill in the alt text and if you if you don't you'll you'll have to do some additional steps to work around that and you can disable this but we wanted to go up and set it up so in the content management systems that if you're adding an image field or you're adding an image in CK editor that you're you're prompted to go off and to do the right thing for accessibility out of the box and if you want to be able to allow your users to just create content more quickly you actually have to do some work to disable those defaults and it's not something that that will that the Drupal community is going to go off and to help you override the accessibility best practices in in the content management system out of the box again you can do it but we're not going to help you do that we want to try and help guide the users to produce better content and produce better sites going ahead so b3 is is that authors are supported in improving the accessibility of the existing content so if you've let's say you've you've imported content or you're cutting and pasting content from a Microsoft Word site sorry from a Microsoft Word document over to your Drupal website how do you make sure that that when you're pasting in content that you're improving the accessibility of that content or if you're migrating from a Drupal 7 site to a Drupal 8 website are there ways of automating that process to see that that the that that content is improved as as you're going ahead so that's that's a useful piece as well and the final piece of the section b is to to have author tools promote and integrate their accessibility features a lot of times people don't know about what are the features that are built into to accessibility I remember talking to somebody about Drupal 7 and there's a there's an option in Drupal 7 to to toggle the weight elements on the the page so if there's a table and you want to be able to do a drag and drop the table to reorder the elements that there's a little block so you could you could disable that with with and with a cookie and then you could go off and and number in the you know what order ranking you want to use use a numbering system as opposed to a drag and drop method to to address that but there's nowhere where we describe that in Drupal 7 so there are people who had who suddenly realized that the drag and drop is missing from their website and didn't know why and there's other people who are like well how do I go off and disable the dragon like I'd like to be able to do this but I don't have a mouse and wouldn't necessarily know that that this is this little text that if you click on this it'll add a cookie to your to your site and will disable the the information and if you want to switch it back you just need to click it again and you'll be able to go off and do that but but there's no documentation to allow that so B4 is about trying to go off and make it discoverable and make sure that there's documentation to back it up because because so much of the time people don't know what what are the what there may be an accessible pattern but they won't know how to get to it and we can't assume that everyone is going to read the source code or be able to to dig in and really grapple with the the issues as in as as like a developer would a lot of the content authors are going to be people who who are not necessarily going to be as technical and are not going to go to the issue queue and find out in in Drupal how to go off and address a particular issue so this is the next slide on Drupal accessibility and sort of combine the Drupal 8 logo with a for the modern accessible logo as two sort of modern accessible logos that have incorporated in there so things we've incorporated into Drupal 8 one of them is the the cke editor integration we've now got a whizzy week built into Drupal 8 that has a lot of accessibility features built into it that the people at cke editor with the help of IBM and others have done a lot of work to try and see that that there are some good accessibility best practices built into that that whizzy week editor and that was the choice of cke editor a lot of it had to do with how accessible it is so we were looking at other options like the aloha editor there hadn't been as much testing and evaluation of that editor editor so something that we we felt that that was a riskier proposition to go off and deal with I mentioned that the choice of cke editor falls nicely into B1 and if you're doing things like bolding text in cke editor it will actually use the strong tag to go off and to bold the text and it'll use the m tag or emphasis tag if you italicize the text which is a more semantic version of the B and I tags for in HTML the we've also created the required alt text as I mentioned that falls into B2 we've included the option for headings and span tags within the default filter in the body text and if you're writing a this may sound fairly trivial but if you're writing a long piece of work and you don't have the option by default to be able to put in headings to break up that content into to smaller chunks so that people can understand how that that law long piece of text is structured then it's going to be difficult to go off and to to to maintain your your accessibility because you really want to try and just for readability you want to have it broken down into little sections so people understand how how in from the into more sort of bite-sized chunks and that's something that's being being being included in by default in Drupal 8 as well the span tag is useful for for languages so if you've got let's say if you're you've got an English page and in the middle of the page you've got the phrase je ne sais quoi in it or something like that you know if you don't wrap that in a span tag and define that language as as being French then the screen reader is going to try and read it in English and it will be worse than my French so it's it's about trying to go off and structure it so that you can tell the screen reader to read it in the appropriate language and that again that's a nice way to go off and to to to provide more semantic information about the text and the content you're creating we allowed we structure a spellchecker into into Drupal 8 as well so by default you're going to you know people don't think of misspelled words as as an accessibility issue but you know how is your screen reader going to just to pronounce something a text that that is is is misspelled is it's hard enough trying to go off and produce a text to speak speech generator that's dealing with words that are spelled correctly but when you have you know people with typos and and bad spellers trying to go off and enunciate words it becomes much harder to understand what is actually being said and we've also incorporated a summary and caption elements into the views tables again making sure that people can can define the table and how it works and make sure that the screen readers can understand if how a complex table is structured and just making sure that that's built in and much of the admin interface in Drupal is now being presented with views as well and now that views is part of core in Drupal 8 this is something that that is is much easier to to to manage and add additional context within within core as well I've already mentioned inline form errors and there's help pages we've added elements in the help pages in Drupal to try and make it easier for this information be discoverable and you know it's a this is you know some of the stuff that we're we're looking at we're only really scratching the surface of how we can start thinking about a tag in our our process so this is a washroom sign in somewhere where they had a wheelchair accessible you know washroom signs with a woman holding a paddle which I thought was a lot of fun so hopefully in Drupal 8 8.6 or 8.7 will start to see things like color contrast for the color module there's there's been a bunch of work that we tried to do to try and let people know if they use the color module and they set some you know colors that do not meet the WCAG requirements that they get a notice of this to say this is going to be hard for people to read and and some basic notice about that would be really quite useful and it's something that that we can do you'll be useful to go off and to provide a notice of duplicate links in the menu structure we don't do this now but but we should be able to identify when a menu structure is providing the same description for the same link and to say okay well maybe there's a problem here maybe you need to rethink how your menus are named or how your your links are set up because maybe they go to the same place maybe they go to different places but this is stuff that that we can use the content management system to go off and help guide our users and to identify whether our potential problems we can always use more help text there's a lot of work with contributed modules there's there's a I don't know anyone that that is is looking at building a Drupal 8 website just with Drupal core there is certainly a lot more possible and and there's a lot of flexibility that's being built into Drupal core to try and think about what could be done with almost no contributed modules but in general people use contributed modules to try and enhance the flexibility of your site but how do we try and take these ideas that we've started in core and apply them to to other contributed modules it'd be wonderful to often have more automated testing built into Drupal as well there are efforts to try and look at at well it looked for a while that we'd be able to use ck editor's accessibility plugin to be able to to have that enabled by default so when users were creating content that we'd be able to to simply give them an indication when they're in that there's a problem within ck editor unfortunately ck editor chose to use the jQuery JavaScript library to go off and to do this which was a great idea at the time but unfortunately the developers of that which were quite steeply connected to the Drupal community they basically stopped implementing the jQuery the the library for for the quail library so the the quail JavaScript yeah quail js library is no longer officially supported and people are recommending that these acts core for for that type of automated testing but we we don't yet have a mechanism to go off and and to to expose that to to the users through ck editor and so that's a much further issue and it's an issue that the ck editor community is going to have to deal with as well because they have they've released the an accessibility plug-in using the quail js library and and it's it's a yeah it's no longer supported so they're going to have to think of some alternative to make make that addressed so yeah there's a lot more that still can be done for for users this is a street map of my neighborhood my old neighborhood and looking at sort of what we can do thinking long-term as well there's there's more we can do to try and provide better support for html five an area providing descriptions about particular blocks what are the what is the purpose of this block what is the purpose of this text and can we provide it can we give the authors the option to to to provide additional semantic definition of that there there is the in html html five support for long text that's still in there right so there's there's a long text is a is a being a long discussion in the accessibility community and like what do you do when you have a complex image and how do you try and deal with describing a very complex image in a textual form it's not an easy question do a better way to do that down where you okay so it's a very detailed to be where you want to go now you're described by was a one point zero area it's really not for long description because it's flat text you can't navigate it but the other fascinating thing of course is that there's a whole question of how do we merge the area standards into the html five standards and what's the future of that those two standards going to be and knowing that it is a real challenge it's still a final recommendation so we need some kind of a solution in Drupal to deal with long text images and we don't have one right now I mean right now there's no way to go off into to tie either with area details or with area described by or with with html five long text to provide information for images that are very complicated and that's something that that should change to allow the user interface to be able to produce content that is accessible and you know there's there's work that needs to be done on that the I'd also like to go off and see some way to go off into to evaluate all text to see that it actually is relevant you can we've got the ability to go off into to check to see that all text is there but we're not checking to see whether or not something just wrote image or flower or dog like it's there's there's things you could go off and and provide a recommendation engine to go off and say you know you can either tie it into an automated one to go off and say you know you know this is what you wrote but but Google the Google bot has said this is this one better than what you pretty like which one's the best description of this is this is being done or or even guiding people through the process to say you know it looks like you've just used the file name but maybe you should tie this into your content and this is how you would you know what is the meaning behind this how do you take something as as as simple as alt text but to describe it to a content editor so that they understand at the time that they're creating the content what they're trying to produce the figure in caption is another one that that I'd like to go off and have incorporated into the well we actually do yeah we don't have have support for that within the image widget in Drupal but it would be nice to be able to provide a structured caption within that so that you can you can have that structured as part of Drupal core there is a figure in caption element that's available within CK editor but but again these things change so the approach that CK editor use for their figure caption module or for figure caption tool was the old approach to dealing with figure in caption and it has been updated since then and the CK editor folks have not updated how they're doing with it and there's no way to go off and to to map that within CK editor to say if you've got some legacy content that's using the old approach to doing figure in caption how do you update the HTML to the new text once you edit that page to see that it falls it along I just want to read if anybody knows about this discussion about the figure because there's people who are saying that it's not appropriate for images because it was essentially a type of diagram whether or not HTML is now or really the end is definitely there's no discussions and I'm aware of controversy about using images at this point but I think it's it could end up in another long desk where you don't need to have support the question at this point. So it's kind of like we shouldn't be using it or we should be using it or we should just stay with the image pattern? I mean so much that comes down to if you have a caption underneath the text that's describing it that's visible then you should use big caption. If you but if you don't have a visible caption then you can use just all text describe the image but but it comes I think it comes down to a design chase about how you want to have that image presented and a lot of times people don't want to have the caption information visible to to the end user for aesthetic reasons and or don't want to work that into the content structure in that kind of a structure. So your suggestion is to use as a system technology book as opposed to a web pistol. I think it comes out of the designer and how they want to have the content presented. There's not necessarily an easy way to go off and say this is there's no necessarily one right way to go off and deal with that. I think so yeah. Let's see. So I do have I want to go off and include a time for question. So I'll just quickly go off and deal with the one of the closing slides I throw here is is the people think about open source they think about free isn't here or free isn't speech and I just want to remind people that it's really should be free isn't kittens. The Mrs. Joe is getting for two cats here actually but it's if you don't support the open source community if you don't contribute back in one way or the other to to this community you're going to find that that you're going to get burned by by modules not working not being upgraded and that it does it's really important to find ways to go off and contribute back to the community whether it's being an individual donor to events like this or being able to contribute code back or even contributing funds. It is really useful to go off and find ways for individuals and organizations to contribute back and having having ways to there's so many ways that can be done to look at enhancing accessibility and this is a you know we've only released a couple of slides in terms of what's possible with Drupal and there's so much more that I'd like to see this community do and it's fortunately a growing number of people internationally that are working on these issues and pushing this forward but it's really encouraging to see so many people presenting about accessibility here at Drupal Cone or sorry Drupal North but we need to go off and have more people engaged so you do think about you're looking at the issue queue and finding ways to to get more involved and with that any questions please let me know the talk next door is going to be a good one as well so please make sure that you take good care of and look at the case to keep it in mind