 Hi, welcom. Fe yw'r oeddaeth y gallwn yn y gallu'n bod yn rhaid i fi, mae'r peth yn gyflawni'r chyflodiadau ar gyfer bwysig ac i'w ddwylliant. Rwy'n gweithio rydw i mi, rwy'n AMDRU ac rwy'n gweithio i annatech, ran yna yma, y gyda'r Llywodraeth Ysgrifennu Ysgrifennu Ysgrifennu Ysgrifennu Ysgrifennu, ar gyfer beth er mwyn i'w ddysgu'r adeiladau yn y Llywodraeth yn Ysgrifennu Ysgrifennu Ysgrifennu Ysgrifennu, We took four awards and we're going to be insufferable about it today. So, but as well as working for Anatech, I've been in the Drupal community for a number of years now, and earlier this year, Mike Gifford, who's one of the accessibility maintainers, he asked me to join him as another core accessibility maintainer, in particular working on this side of the Atlantic Ocean. Mike and Jesse are the existing ones for Drupal 8, and they're both in North America. So, yeah, this summer I became an accessibility core maintainer, and I'm still kind of finding my way around it and learning what it's like to be a maintainer, and finding immediately that my participation in issues is changing, I no longer sort of ask timidly, can we do this, maybe explore this idea? I don't like we should do this, and also I'm enjoying filing issues and making plans, and knowing I don't have to be the one who fixes it myself, but instead I'm spending a lot more time looking at more and more issues and triage and review, and what I'm going to do today then is to let you know where accessibility is at currently in Drupal. I'm not going to talk about anything before the Drupal 8 release, I'm going to start with that as a brilliant starting point, and I'm going to tell you about some of the things that are currently broken, a few bugs that we've found, some of the little features that we're bringing, and there's new stuff, and I'm going to talk about some of the things I think are really exciting that we could do to continue innovating with accessibility. When I made the session proposal just a few months ago, I was brand new to be in the accessibility maintainer, and I just had this, it was only a big long session proposal, it was like a big brain dump, and I realised there's no way I'm going to fit all of that into one session. But if there was something you saw there, it's still fair game for the questions. I did think about whether to focus on the strategic initiatives because we saw a lot of interface changes coming in there. Some of those are well underway, and we've got the outside-in module, and I tried to keep up with it, but then I did some travelling over the summer. Now it's there, it's working, it's an experimental module, and we can do some proper accessibility testing on it now. So I might not talk too much about the strategic initiatives. Instead I'm going to talk about some of the things that have been in the back of my mind over the last year or so, which I'm now going to introduce as proposals, a kind of a little roadmap for where we go with accessibility. I don't expect you have to know too much about the nitty-gritty on the technical side of accessibility. I did make that, that's why it's an intermediate talk. It's not going to be too much technical expertise, but I think it's worth recapping to check that everyone knows what ARIA is. I'm expecting everyone knows what JavaScript and HTML and CSS is, and I expect you to know your way around the Drupal interface. Hands up if you know ARIA. About half of you. So it's worth stating that ARIA is another technology from the W3C, and it's intended as a set of... It describes the state of user interface widgets and controls in a way that is machine readable, a way that we can pass up through accessibility APIs in the host operating systems so that they will reach assistive technology, such as screen readers and switch access and other kinds of controls. There's a couple of examples here. We see some of it is static. It's a way of... You can use it to create complex ways of labelling things, or occasionally there's a need to override the way that something's labelled. You can also create... Describe things as user interface components. Here I've given an example of a tab list, which doesn't have an equivalent in HTML, but we do find in the desktop operating system. The last example there, we see an area expanded, and that's something that we can use to communicate the state of something. An example here would be our drop button widget, or our details and summary widget that we use extensively, all across the core Drupal admin interface. If you're sighted, you can very easily see what has changed on the page when you click on the drop button and you see it drop down and you see a whole bunch of extra options. We also want to convey that information to screen readers and other assistive tech. Area expanded is a machine readable way of telling a screen reader that the button is now open. That will toggle between true and false as you press the control. Our details and summary widget does indeed do this, and I know that our drop button doesn't communicate its state to a screen reader, so that's something we'll want to fix, and it's a simple pattern to do so. What's happened since Drupal 8 came out? We have still gone and carried on making changes and accessibility. We have found a bunch of bugs, and I'm going to show you this group in particular, because they all relate to keyboard behaviours, and many of us will be going around using a trackpad or a mouse or some of the pointer device, and as the developers who are working on things in the issue queue, and we may not be doing much manual testing on keyboard behaviour. Some things that happened, we noticed the Ajax buttons. You'll see Ajax buttons around. If you've got an image field and you've uploaded an image, you'll see a little thumbnail of the image, and next to it there's a Remove button, if the editor wants to get rid of that image. If you focus on that button, you'll see a focus style, and if you press Enter, you expect it to operate the button, and it doesn't. You'll see that is the field UI when you're on managed display. You'll find that some field formatters have settings, and you open them with a little button that has a cogwheel on it. That button is also affected. The good news is that we have a fix for this, and there's a patch ready. Some other stuff. We found the CK editor, if you are configuring your text formats, and you want to decide which buttons you're going to include in your editor toolbar, there's a button in there which lets you change the names of the groups and fiddle with that, and it turns out that, as far as I can tell, that button never worked with the keyboard, but we have that fixed. There are some missing focus styles in the CK editor UI. Barris, in fact in the front row here, is working on a patch with that, and there the editor works. You can add buttons, move buttons in and out of the text editor that you're going to be configuring, and it works quite well with the screen reader, but if you're a sighted keyboard user, you can actually operate it just about. The buttons there are focusable, but you have no idea which button is focused because there isn't a visual indication. Recently, I just found out that some of our dialogues don't quite work properly. When we in Views UI, a lot of the settings there open up a dialogue, and if you operate that with a keyboard, whenever the dialogue opens, the focus will shift to the inside of the dialogue. That also causes a screen reader to announce the fact that it's entered a dialogue, which is really important. I found that if you're on the block layout UI, that dialogue doesn't focus the content of the dialogue. You're still focused on the button that opened it. If you press Tab, you straight away get into the dialogue, so something's just not quite right there. Some other bugs which we found, which are not related to a keyboard exactly, we have some labels, a labelling system, we use area labelled by so that our menu blocks, if you know that menus have user menu and main menu, those are the names of the menus that you can configure in the menu UI, and you can choose to hide the block title or show the block title, but if you hide it, you still have a label telling you what the name of that navigation landmark is, and it turns out that they got broken. Bartic and Seven were unaffected. This was after we decided that we were thinking about how to stabilise our core themes, and so the bug is actually in the template in the system module. We have fixed it, and I got to sign off as well that we could make that change in the stable templates too. So that's really, really important for anyone who's making a custom theme and isn't extending classy. It's interesting the way that that bug got introduced too, because we've done a lot of really sensible refactoring in other systems. So there's a lot of CSS cleanup, the best practices of CSS. Generally speaking, we no longer use ID selectors in our CSS, just class selectors, and so there's been a lot of refactoring there, and once you are no longer using your ID selectors, and some of the classes have been removed, because now we have the classy theme, meant that from the system module we could remove some of those classes that are actually provided by the classy theme. So there was an issue which was to go and clean up some of the classes that we never use, and sure enough that went into the template and it took out a whole lot of classes, and you wouldn't guess it by the message that appeared on the Git commit, but it also removed a couple of ID attributes from the template. Those ID attributes were no longer being used by CSS, but they were being used by the area reference system, and so now you would hear that you were in a navigation, navigation, navigation, you couldn't tell these navigation blocks apart, but by fixing that, you can tell you're in the user menu navigation, you're in the main menu navigation. We've also discovered that some templates aren't respecting the ability to hide the field, but include it as an invisible thing. This is, again, on the field settings UI where you say, do I want to show the label for this field or hide it? There is an option to hide it visually, but still leave it there so that a screen reader can hear it, and some templates aren't respecting that, so that's something we need to fix. In fact, I'd kind of like to take that out of templates and have it further up in the pre-process hooks, so that it's harder for a thema to inadvertently break. Here comes a big one. Inline form errors is still an experimental module, and we've now got quite a number of experimental modules in core, and Dries mentioned this in his keynote that we need to move them towards a stable capacity. They can't just live in the experimental package forever, we need to move them towards stability or possibly make the decision to remove them from core. Inline form errors became an experimental module very shortly before the release of Drupal 8. It was intended that this stuff would be just part of the core system, but some outstanding bugs meant that it was something that would delay the release of Drupal 8, and so there was a valiant effort of refactoring. We took it out of the core system and made it an experimental module, but it still has some blockers and it's still a little bit rough around the edges, and we need to get it out there, and so we have until the 8.3 release to make some serious progress on this. It's at risk of removal, and it's a real shame because we do have a great roadmap. We know what the problems are that we need to fix. What we don't have is many people working on it, and so I just want to highlight this. The pattern that we're building with it, the idea that we're placing the form errors in line and that we're placing links in the summary message at the start of the page, when you submit a form it comes back with say three errors. You'll see a message at the top saying which those errors are and they contain links so you can jump to them more quickly if you're using a screen reader or if you're a sighted keyboard user, or if you're using switch access or some other mode of interaction. We have a saying in the community about getting off the island and stuff that's proudly found elsewhere, and those came in as really important philosophies for us in the D8 development cycle. Inline form errors is one of those things. It's very much in line with current thinking in the accessibility community more widely. Many of the experimental modules that we have are forming part of the strategic initiative, so the migrate modules, the workflow initiative modules and the editor experience stuff like outside in. But not all modules are part of, they don't have that blessed status of being part of a strategic initiative. The inline form errors module and also the big pipe module, these are accessibility, usability, big pipe is about performance. They're not the strategic initiatives. These are the regression gates that we guard against. So whilst the strategic initiatives are moving our product forward at the bleeding edge, these modules are important to get to a stable situation because they're actually moving the regression gates forward behind us as we go along. So it is the most important priority for us right now to get inline form errors sorted. I still haven't got my head around the exact full list of everything we need to do on that as a new maintainer, but it's becoming the thing that I have to be looking at more. But what I actually want to talk about for the most of the thing is stuff that I personally find exciting and we haven't talked about at all yet in Drupal Corr. So we have a bunch of new features that we're bringing in and the great thing is that our point releases, our six-monthly releases, mean that we can bring things in as new features when they're good and ready and we can continue to just drip feed more and more accessibility improvements in. We've gone past the time where the Drupal 7 came out and then we thought, oh well that took three years and now we're going to say, well we have to look at the state of support for ARIA in screen readers and browsers and go with what works because we might not have another stable D8 release for another three, five years, but the six-monthly releases blow that all away. It's not just every subsystem in Drupal is going to benefit from this. So the CK editor, Aliecheca, it was a proprietary plug-in which you had to spend money for and it was produced by a CK source who are behind the CK editor thing, but they've given it the GPR license now, so we want to bring it into core. We are blocked on an upstream packaging issue which gives us a JavaScript performance problem. But there is a contrary module available for those of you who want it. If we can get this by 8.3, that would be fantastic. Here's what it looks like. We see the editor, we get an extra button in the toolbar with a little icon of a person and that's the accessibility checker. It goes and finds your accessibility problems inside one of those rich text fields and then it kind of gives you this little wizard-like interface. It tells you the seven errors and you can skip through them and it offers you advice on how to fix it and an inline form to help you just do that quick fix here and now. This will be a brilliant thing to have in our rich text editor by default. Views tables with two headers. I can't tell you. This is one of the things I am so excited about. There's a bunch of images here which show that there are different structures for tables. We see one with just a set of headers across the top and then other kinds of table where it makes sense to put headers across the top and down the sides. Then there are a few more complicated ones like the two rows of headers which have multiple column spans and things. Currently, the output from views is just one of those, just the top row as headers. Someone submitted a bug report saying accessible tables must have column headers and that's not quite true actually. These images come from the accessibility tutorials at the W3C. Thinking about it, it's a great feature request. Could we just have an easy setting in views to say, actually I want to pick one of my fields and say that that's going to get column header, row header status. Here's a use case. This is a snapshot from the foyer downstairs. That's a Drupalcon schedule, so timetables. Also product comparisons, track listings on a playlist. These are things where it makes sense to identify one of your columns as being a good one for treating as a row level header. We have a patch in progress. We needed a design review because here's what it looks like in Bartick. I've taken the content listing and just taken the node title and said treat that as a row level header. It's great for accessibility because whilst you're using assistive tech like a screen reader, many screen readers provide tools so you can query where you are in a table and discover things. I'm on this cell, but which cell is it? You're in row 3 column 5. You can ask a screen reader what are the headers for this and it will tell you, actually you have two headers in this case. The screenshot we also see here is actually the second column which we're treating as the headers. Checkboxes are the first one but the one we're using as the headers is the second row. It's flexible enough to support what's called tables with an offset column header. It's actually just one little select box in the UI for the views tables. None is an option, but you can say use this one. We're not proposing to change the views that we're using in core but we think this is a really great site builder tool just like the accessibility checker in CK editor. These are tools which are going to help authors make decisions about which effect accessibility. Drupal Announce was a new API we brought in in Drupal 8. Has anyone heard of it? Has anyone listened to it? It uses Aria and it uses JavaScript to manage an invisible div but that invisible div is marked up in a way that a screen reader will read out anything that changes there. So we can use this to sneak in some custom announcements. Brief custom announcements please to just give a few changes, give an indication of what changed on page. We use it in toolbar when you change from the horizontal toolbar to moving it to the right-hand side as a different mode of looking at the toolbar. There's an extra announcement to say that just happened. We use it in module filter. I thought we'd have a quick demo. So we've been to this page. Let me just... Skip to main content, site administration. Shut up. If you learn to use a screen reader you'll learn to use the shut up key. That's the first control you'll learn. So I'm just going to skip. If we're in the... The idea is that we have a text field here where if we start typing in it it's going to reduce that big long list. Now there's no page refresh here. We're not sending back to the server and getting a brand new page. We're just filtering dynamically locally. So we need to communicate that change to a screen reader. So if I type the word cache in here the core has two modules with the word cache in the title. We're going to hear a modern accent. I can detect the test modules. But... Eight modules are available in the modified list. Eight modules are available in the modified list. It was the feedback that a screen reader user gets. It's minimal. That is a short message of visual change that just happened. Something that is very, very apparent if you're looking at the screen and you can see the visual change happen. It doesn't handle plurals, right? There's a patch for that. So we'll come back to this interface later. So there are more places in Drupal Core we can use Drupal Announce. Here we're rounding out places where we missed an opportunity. We have quite a lot of filterable lists. If you're adding search criteria or search criteria to one of your views, you get a dialogue and you can filter by the category or search for a keyword. I need to add the title and you see type title it reduces your number of options. We can make the same kind of announcement there. The block listing also does that. There might be things that we can do with if you have Ajax views enabled and Ajax is being used for exposed filters to just do an Ajax get a updated version of the view. There's no full page refresh going on. So a full page refresh will normally have the title of the page announced by the screen reader. That's the title that you find in the HTML head. But without a full page refresh you don't have that. There are lots of places we could use it in contrib and in fact refresh this module that's a beautiful thing which is a performance enhancing module and it has no configuration, you turn it on and your site gets faster. Who wouldn't shove that in? But it does so by avoiding full page refreshes and so the title of the page that you've just navigated to is missing and straight away I could see that this was a use for Drupal announce and so refreshless is still a contrib alpha module but it does indeed announce the name of the page that you would have got if you had done a full page refresh. Views load more is one of those things where you have a button at the bottom and you go loads and other 10 teasers that would benefit from one. I must get around or maybe one of you could get around to making a contrib patch for that. There are other places we could use them. Fassar and the search API are long well in Drupal but those can be run by an Ajax so it's particularly useful there because you might have your facets down in a sidebar and the results are displayed in the main content area and if you're dynamically changing those as you're ticking boxes in the facets a sighted user can see the new results are there. What we would like to do is say Drupal announce would be a great way to read out the crucial piece of information probably the header of the view where it's telling you there's eight results for 80 litre backpacks and it reminds you what facets you've got and it tells you how many results you've got and that's important because you might not be finished with messing around in the facets in the sidebar. You might want to pick a few more and bring that result count down. There's some other current stuff. Some of our focus styles are way too subtle in that some of them are really bright and bold and some of them you just have difficulty seeing. I'm going to show you one. If we go hang on. I'm going to go to the managed display for a node type oh here we are so we're listing the content types and the basic page and over in the operations we've got one of those drop buttons now I'd like you all to close your eyes and we'll have a little experiment and I'm going to press tab a whole bunch of times to get somewhere and you can open your eyes and tell me can anyone now tell me which element is in focus what's going to happen when I press the enter key yes it's wrong No it was the drop button arrow doesn't have a good focus style and it's because we're really using hover style and I'm just showing you this because if we are hovering a sighted user is following the mouse pointer and has an extra clue and we see this tiny subtle background colour change it's too subtle we need something stronger than that focus style is mitigated by the fact that the focus style for managed fields is a big underline and so I end up finding my way around and going okay I'll focus managed fields and then I want the next one after that tab once but it's such a subtle focus style that we could improve back to the presentation and just as I mentioned earlier we have not all templates respect the label display setting for field API so we want to fix that but actually we want to extend that functionality to the block titles and the minute you can either have the block title or omit it completely but we'd like to bring in a visually hidden block title sometimes you might run a series of blocks together but they're actually related and you don't need a separate heading for them both that will be another site builder tool to affect decisions about what the accessible experience will be so those are the things that are currently going on in core just want to tell you some of the things that we have never touched on yet in core really but we these are some modest proposals a little bit of a roadmap if you will can we have automated testing for accessibility stuff and the really cool thing is we now have a functional javascript test which it runs interactions in a headless browser and those headless browsers are capable of running javascript so I'm really excited about that but just to cover the sort of strategy or the outlook on this what we're doing here is that accessibility is about managing the whole DOM the whole document object model that's the HTML source and then you style it with CSS some behaviors get added with javascript and then the user actually interacts with it and further changes happen and maybe some area properties get toggled area expanded true area expanded false maybe the content of that Drupal announce invisible div gets updated with a new message so we want to know that after the user has done something the DOM is now still in an accessible state or that some of the things that we have put in place as screen reader messages are still being announced so here's some ideas I've discovered that mink which is part of the javascript test base it's part of the infrastructure of that it turns out it can drive keyboard events distinctly from mouse events in its tests and I'm very excited by this because I mentioned that we had a lot of keyboard accessibility regressions I mentioned the Ajax buttons had stopped working now we have a fix for the Ajax button issue but could we actually put a regression test in the idea is that you would load up the page and you will find your way to the button and focus it then explicitly press an enter key using the mink driver and then make your assertion that the form has changed and that means that we can have coverage because the problem we had is that the Ajax button still worked for a mouse click but it hadn't worked for a javascript click the commit that introduced that bug was a refactoring of the Ajax system which made it easier for javascript authors to set it up it was just about making a nicer developer experience for the methods that are written in code to actually make something an Ajax button but then I hit a snag it turns out that I wrote a test and I got the test to run and I was really pleased that I had made my first functional javascript test and the test passes regardless of whether you have applied the javascript fix so manual testing confirmed that if I change this line of javascript before the patch the Ajax button doesn't respond to the enter key and after the patch it was responding to the enter key but the test passed either way so what was going on there well I had a really useful conversation with Daniel Vayner earlier in the week and he knows a lot about how that test framework is set up and it turns out that mink is just to drive a wrapper to normalise a bunch of other drivers which do things differently all we need to know is a key press and it translates it for the other drivers it turns out that the Goot driver does not support key presses it turns out that the Zumba driver for PhantomJS that we use with our new functional javascript test base I confirmed that that was the driver that was being used with a filthy little echo statement for debugging and yes sure enough we're in that class and it's if I take out the key press thing sure enough the key press line of the code the test will fail so the key press is happening it's being registered but for some reason it's just not behaving expectedly well it turns out that we may need to switch driver and actually test keyboard accessibility simulate key presses using something like Selenium which actually gets your browser like Firefox to do it that's going to be a resource hog if we had to do that for every single testing in core use Selenium that would just put a big strain on the CI setup so maybe we can use different drivers for different tests that might be a solution I've skipped ahead that's in the later slide but the idea is that mink can drive keyboard presses decently from mouse actions so we can build those regression tests in ideally if it doesn't just turn out to be a pipe dream other things we might do with testing is confirm some area relationships I said that there was a template that broke where an ID had been inadvertently removed when cleaning up some classes a regression test to confirm that the ID referenced by that area described by or area labelled by still exists this is a way of connecting two elements it's a bit like the way you have a label has a four attribute that points to the ID of the input attribute it's the same principle it's an ID reference which one there's a lot of relationships we can do to get the right relationships for some custom form elements like our detail summaries or field sets or complex compound fields like the UI element for something like the format the widget for the link element you're expected to provide some link text and provide some URL text so there's a multi level compound field set so there's other relationships we can confirm and because we've got something that can drive JavaScript and then we can inspect the DOM afterwards we can make some we can't write tests automated tests that drive screen readers yet but we can do a poor man's version of it by doing some changes go into the toggle button toggle in the toggle and then confirming that area expanded has the correct value afterwards so that's the state of the DOM after the user has interacted and caused the DOM to change that's what we'd be making an assertion about is anyone here excited by this yeah I am excited because we might attract more test readers to learn about accessible, expected behaviour yeah writing tests is also something that holds up issues being fixed so here's a quick example a little bit of pseudo code we had that Drupal announced we saw it earlier, we listened to it earlier in the module filter when we typed cache and it told us that now there are only two modules available in the modified list so the way that we would do it is that this is the div with an idea of Drupal live announcement live announce that lives down at the bottom of your HTML footer so the test would be something like this this isn't code, this is just the process we load up the modules page and then we go to the module filter and then we type field or cache or something and we'd wait for the I'm not sure if we'd have to program the wait, we might have to program a wait while the DOM changes and then we actually go and inspect the DOM and we'll go and find out how many rows actually still exist and it might be eight and then we'll go and look at what the announcement message says and we're expecting it to say that there are eight modules and it's going to have the right count so that's just an idea of how we would write a pseudo screen reader test exciting so we do have some questions the key press doesn't work as expected I'm interested to know whether we can ask which element has focus because we can certainly say find an element and focus it I want to do it the other way around I want to say what element has now got focus I mentioned the bug that this could test in the block placement page on the block you press place block and the dialogue appears but the focus doesn't move inside the dialogue and therefore the dialogue isn't announced but if our test can say can assert where the focus is after an interaction then we can we can guard against that Mink also takes screenshots so we can start a test and say take a screenshot the question I want to know is can we actually assert that two screenshots taken during a session are different so the idea here is that we could load up a page and find a button and say focus that button and then take a second screenshot and if those screenshots don't differ then we don't have a visible focus style this might need some more thought Boris is wincing so I don't know if it's actually something that you can assert but it's an idea it might be that another tool could do it we might not need the coordinates that's the thing we just need to say all we have done is focus one button that was a comment my question can we test screenshots a member of the audience in the front row said that he thinks it might be possible to do that so it's something to follow up on later on it's something I need to get into the issue queue for the right people to answer windows high contrast mode is anyone ever heard of it anyone ever used it nope once also just a quick how many people here are developers or designers or otherwise building websites how many of you use a Mac it's the same hands now here we've got a disconnect with our audience because windows is still 90% of the desktop market share I think it just dropped below 90% for the first time and it's a user interaction mode that isn't available on the machines that many developers are using so there are many operating systems which offer some kind of tool for people who need some kind of adjustment to the colour space windows high contrast is one of those colour inversion is one of those and the tools that are available differ greatly between different operating systems and they're usually a feature of the operating system as web developers we're usually concerned with the differences between browsers and we also know that if we're testing with say firefox we know that firefox on a Mac and firefox on windows there are very few differences between them but windows high contrast mode is something that is only available in windows the way it works it's been around for a long long time and why I'd like to suggest we support it is because it's very stable and it's made very few changes in the last 10 years or so that it's been around and it gives you various more extreme colour variants like a light on dark or a dark on light and here's a screenshot of what the Drupal you do the standard install you've got through the install process bang you're logged in and congratulations you installed Drupal this is what it looks like anyone tell me what's wrong with it ok the purple text is fine but the header is an interesting one you see the weird dividing lines that we've got in the toolbar now in the normal colour space we see that the top row of the toolbar is black and the bottom row of the toolbar is white and so you can tell the difference between the two rows here we kind of don't have a divider line between the top and the bottom but we do have these weird divider lines between the buttons and they kind of just look odd on their own any other differences yeah the icons have disappeared where have our icons gone if you look at the toolbar there's lots of icons in the toolbar and they're missing but all of those buttons in the toolbar have accompanying text label it's an icon follower by a label but we can see in the Thomas just mentioned in the search box we have the search input field and then we have this rounded corners button with nothing in it whatsoever no image, no text over on the other side of the screen you can also see a little circle because I was hovering over something and that's a context contextual quick edit button it's just a round circle we would expect to see a little edit icon in there where's our RSS feed gone that's just an icon you can actually see it because it's got a link underline it's just the image itself that's missing and the border on the left hand side of the congratulations you installed Drupal message has also gone but we've now got a three sided box instead of a four sided box why is this this is the effect of high contrast mode it overrides your colours that's fairly obvious it changes the front and background colours there we saw the yellow on black and things like links were kind of purple background images are stripped the assumption is that background images are going to interfere with readability because there's going to be text over the top of the images did anyone look closely at the program for Drupalcon the timetables have got icons behind the names of the events and I think it's quite difficult to read that's the philosophy of stripping out background images in high contrast mode but our icons are placed there using CSS background image but they don't actually have anything overlaying them as text they've actually got some space reserved for them our border colours are overridden but our border style width and radius are respected so we saw those rounded corner buttons we also saw that the message had a three sided box and the big thick border we were expecting disappeared just because three sides are a one pixel solid border and the other side doesn't use CSS border it uses CSS box shadow and that was out so can we suggest a fix for that we can swap that CSS box shadow for a CSS border and we will I've tried that I've messed around in Firebug I've tried that it works so the question now is how much of this survives and the reason we want to see how much survives is we want to see that some of the same design affordances are carried across so that there's a kind of parity an equivalent experience in this new colour space some of our design you can say is clearly cosmetic but there's more to design than cosmetics some of it is functional we expect to be at a tell row one from row two and that's why we gave them a different background colour but when we saw that actually you can't tell the difference between background colours because there wasn't any border involved in that so if you just had a black background and a one pixel black border well that border would persist but it would be changed it would change its colour some things work really beautifully look at the install screen for Drupal and we've got a batch a batch progress going on and we see a progress bar and this I think looks really really beautiful the colours have been changed and the fancy animated barbers pole stripe has been taken away but the essentials are still there we can see how far along that progress has gone because that border radius has been preserved and so we know that this is not just a rectangle divided into two we actually know that it's a rectangle growing it's this lozenge that's growing inside it's something that's filling up and we see that from that preserved border radius there's something else that's changed here the level which says install site we would normally have a little in the normal colour space you see a tag and it's like a beige tag with an arrow tip well the background colour has gone but then we see this weird yellow ugly square where's that come from the triangle is actually a CSS border hack so what we have is a kind of probably a one pixel box with a 50 pixel border and what they've done is they've achieved the triangle by having a coloured border on the right and transparent borders around and the transparent borders are respected but recoloured and so now we just have this big square thing so the things we could change here's what a dialogue looks like and how do we recognise that it's a dialogue we see that the page in the background goes out of focus but we see that I'm going to need to speed up we see that the thing in front has got rounded corners, it's got these headers and stuff and the colour space of high contrast that's where it looks like it's just kind of a bunch of text floating there what if it looked like that that was achieved with one pixel borders which were transparent it changes nothing in the normal colour space but provides this extra affordance that tells you this looks more like a dialogue yeah the closed button is a background image techniques we can do, I've talked about the one pixel border it also applies to outlines but we can replace CSS background image with generated content we might also be able to have recolourable icons if we can convince people to use icon fonts, those are rejected because of a performance concern of having to download a font and I'll briefly run through area usage, this is my last section, we introduced a lot of area in Drupalate and now Mike has the idea, Mike Gifford has the idea that we might have used too much I've also shown you those places where we've got gaps and we could introduce more like area expanded on the toggle button so the real question is did we use it well and there are some emerging practices this is the getting off the island and proudly found elsewhere part of it Drupalate started five years ago, six years ago and support for area was still patchy in various browsers and different screen readers had different support for it that's come on a long, long way the level of support has increased and now the authoring, I'm on the wrong slide the authoring tools was one of the things we brought in as a new standard and it was full recommendation a month before Drupal was released we were one of the implementations being tracked Drupal's implementation of ATAC was one of the things that helped it become a full recommendation just as browsers are the things being tracked for making CSS modules a full recommendation making the HTML5 a full recommendation well, area 1.1 and area 2 are in the draft stage and there are things coming in there that we could use and so we might be an early adopter of that which content management systems are using these things there's an accompanying document called the authoring practices and this describes a set of patterns recipes if you will for how to use area to create certain widgets and a couple of weeks ago accessibility conference in Edinburgh I was fortunate enough to meet the editor of this spec and had a really informative talk about whether Drupal might be able to implement some of these an example would be recipes of tab sets and dialogues and things and I was wondering about whether we might change our vertical tabs which has been around for about 8 years it started as a contrib experimental module in D6 became part of core in D7 it's still with us and it's been refactored a bit but we haven't ever looked at its behaviour and it doesn't have area attributes to describe it as a tab list so we might be able to implement the tab list pattern in Drupal ourselves or we could actually throw out our vertical tabs and look at jQuery UI which also has vertical tabs and say why don't we improve that one and contribute upstream in that way Drupal has got area vertical tabs but then so has everyone else who's using jQuery UI got the right thing so that's just an example of something I think is an opportunity to get off the island and be part of emerging web standards real user testing is something I'd like to bring in I want validation of our designs because the people who are currently testing with screen readers we have screen reader users in our community who are self-identified and said yeah I use a screen reader I'll help test this the downside is that they actually know Drupal very well and usability testing we want to take things to people who don't know Drupal very well they're also power users and we want to know when everyone with a screen reader uses all of a screen reader's functionality so some real accessibility user testing will be a great thing I have zero experience of organising that we might want to try and raise some money and get some external agencies to carry that out we might want to try and run it ourselves how do we get more accessibility contributors I'm still pondering this but one of the main barriers is the kind of manual testing that's involved and the sheer learning curve of finding out and familiarising yourself with how a screen reader works and of course they all have different keyboard shortcuts and they all have very different behaviours in terms of what they announce and how configurable they are and the actual expected behaviours are something that we would have to educate more people about so that's a big challenge to answer for you I've talked a lot and we're at 54 minutes so I haven't left much time for questions and I apologise for that you might have time for one or two questions Ifrik we're having contribution sprints and Barris has persuaded me that tomorrow we're having an accessibility table at the contribution sprints so Ifrik Thanks a lot I think this is really interesting and really great and yesterday we had a core conversation about UI standards and I think it would be really good if we can to some degree coordinate between UI standards and accessibility standards so that we're not coming up with UI standards that don't meet that or that we make model developers to look here for UI and here for accessibility so if we can actually combine that that would be really great for UI texts we have and I've no idea about the announcement text so we should for example take that because they're not visible so you don't think about them in your planning as much so if we can maybe on Friday sit together and see how can we integrate that better the other option I've been wondering whether for modules we could actually make something visible to say I'm pledging to stick to we have had that as a kind of a hashtag that points in the past as a D7AX but if we could also visually make that visible on the module sites that also might you mean more like the security shield icon which is provided automatically I think but if we have something visible to say we want this module to be accessible we're trying to make it accessible or we pledge that it will be just to make it more visible to users also when they choose a module so that helps evaluators and contributors we will follow this up those are both great ideas just to repeat Barry's comment for the recording my job is to look out for things tagged accessibility in core but the tag if you put that on any issue in a contrary module I will see it I may not prioritise it but I'm very happy to help contrary module authors with accessibility issues it might be good to do that on a basis of something like office hours the usability team ran usability happy hour for a while where you could go and get a quick 10 minute expert walkthrough of your UI admin settings and stuff like that hi at the back they recently passed a law that forces all these early websites to be AA grade accessible and all these companies started popping up and spamming our clients that offering these tools to embed in our websites and I just want to know how how viable are they how will they cover that type of accessibility depending on who you ask which accessibility consultant or enthusiast you ask and you'll find very different opinions on this the I'm not enamoured with them there was some time to refer to them as bolt on accessibility an example of this might be you can get screen reader type things that you embed inside a web page there are various offerings there but if someone needs a screen reader they're likely to need it for every single web page and in fact there are other applications like their editor and file manager on their operating system so what would be the benefit of just putting a little bolt on web reader into one particular website there might however be a few use cases for it like if it happened to have a really good voice that was trained in the content of the page but it's not just screen readers it's also javascript applets that change contrast increase font size stuff like that some of them work but windows high contrast for instance is part of the operating system but there are also things that people do to make use of browser plugins which will just they'll only affect your browser experience but they'll affect every single web page you visit there will be things like toolbar buttons and stuff of course font increasing and decreasing can be handled by browsers themselves and you can put if you use it a lot you can put a button in the toolbar so putting things like that inside a web pages I'm generally against but you will find accessibility specialists who think otherwise and disagree with me it's a big topic I don't want them in Drupal is one thing to be saying thanks anything else ok we're nearly on the hour so let's make this the last question I'm a bit too small but there's one blind user I'm very concerned with for anything IAX Google is blind too also we're refreshing pages without refreshers are concerned is there any experience that Google reads the Drupal announce or might do it in the future I hope so I hope they don't because it's not intended as a search engine optimization no but they tend to act like they're blind they tend to use everything that blind people use also what would be wrong if they do that read it Google presumably well Drupal announce messages will only appear after user interaction so we'll kind of assume that for that to happen Google's bots would have to be doing interactions with the page follow links that may well end up happening I don't know whether it's taken into account by search engines whatsoever the thing that I would hope though is that Drupal announce messages are probably considered to be irrelevant and they're not what the page is about so I don't think they but we do know that Google prioritized pages based on performance or based on their responsiveness and who knows they might actually start doing accessibility because sometimes changing facets opens content that you want on Google and if you don't know that something happens when you're blind you don't ever see those content types maybe that's what the Drupal announce is for there are other libraries Drupal announce is Homegrown Material Design Polymer, that's what I'm thinking of Polymer has a component that behaves similarly there's a jQuery accessifier that's got that ability too there are equivalents outside of Drupal just wondering if you have seen anything no sorry I might not be the best answer so thank you very much that was a question lunchtime