Web Accessibility - A first look at WCAG 2.1

Hi everyone, and hopefully everyone can hear me. This is a first new piece of software.

So,

thank you for listening. This was something I first presented at a conference in Bristol, and actually since then, I’ve added to some two parts of it with changes that have happened since June, and the guidelines. So, I will kick off.

So, as a quick introduction. I’m Alastair Campbell director of accessibility at Nomensa. I’m not particularly going to talk about why accessibility is important,

there are quite a few good talks on that. I’m assuming that you’ve seen one of those, and would like to go a little bit further. So, during the presentation I will start with pretty much the quickest introduction to accessibility that I think I can do, and get stuck into the changes that are coming up. I’ve created the links used in the presentation, and I’ll share that again at the end. If you have any questions, please do ping future accessibility, the future 811 way on Twitter, or there is a chat feature or questions feature in GoToWebinar as well. And my colleague will be monitoring that because I will try and concentrate on what I’m saying. So, to start with, I’ll start with how I see accessibility fitting into digital projects and accessibility overall can be seen as a mismatch between the person and the environment, in the sense that it’s, it’s quite a wide topic. Permanent disabilities often have equivalent sort of temporary or situational impairments. So these figures are from Microsoft’s inclusive design toolkit and show some permanent temporary and situational impairments. For example attributes of a design such as contrast can help people without visual impairments using their phone in strong sunlight, or as we discovered recently clients who happen to have cheap laptops laptops with not pretty good displays the contrast on those wasn’t too good either. And, however at its core, accessibility is about people who have disabilities. And I often talk about it as a form of usability because accessibility is about whether somebody can effectively use something easily effectively use something which is very similar to how usability is defined. But where it tends to differ, is that there are many different access technologies in use. So, the technology might help somebody adapt to things or use it in a way different than what you might be expecting or what you might be used to. And really the platform standards, help with this aspect because they help to outline who’s responsible for what. So when I presented this in Bristol, about six weeks ago I asked how many people use some form of accessibility guidelines in their work, and about half the people put their hands up, which was somewhat encouraging. And it’s really worth knowing because the guidelines help to provide a baseline responsibility for people creating products. So some things are the responsibility of the people creating products and some things are the responsibility of the users technology. So it’s, it helps to define the sort of contract between how those two things work. And they’re also useful for governments to inform laws, such as procurement laws. However, when generally talking about accessibility or introducing people to accessibility. I don’t start with the guidelines and I found it. Lisa some odd results, like if you imagine you’re in a wheelchair, following directions you get to this lovely accessible door button. The buttons in reach the door automatically opens, and you’re faced with a set of stairs. It’s not a great experience. And to top it off, money was probably wasted putting in this accessible door because it wasn’t thought through. So when people start learning about accessibility, using the guidelines, they tend to end up with results in the digital equipment, a bit like this, where the fault is left too late in the process. And then you go through quite a painful process of pulling accessibility from the end of the project, further up the process. So, when running workshops and training, I use an interaction that approach, I get people to try these four sort of tentpole interaction styles, where people use the keyboard only, which pretty much equates to input output independence. So in web development terms it means that you can use everything with the keyboard. It’s also worth testing that people can make things bigger, so that if you can’t see very well. You can zoom in and still use everything. And then there’s also including the right structure and metadata for people using things like screen readers, so they can understand what the content means, and making things easy to understand. So people have come to their payments or language issues don’t get lost. That is a real picture of a public footpath sign, which has three different directions you can go on a public footpath, and I was none the wiser as to which way to go. So, all of the accessibility guidelines can fit under those interaction styles which helps to cover your bases and from my point of view, it helps people understand how accessibility works a bit more quickly and easily.

And when I’ve run these workshops. I often get people to run through the guidelines one by one and say, whereabouts in your process. Can you define how this is going to work. So not necessarily where people can test for accessibility, but when they can define what the accessibility attributes will be. And when I run this, the results are almost always very heavily focused on the sort of early low fidelity prototype sort of stages, which isn’t to say that you can test these prototypes or even just paper sketches for accessibility, but it is at that point where you can define how it should work. So, wherever you are defining things whether it’s in brand guidelines sketches designs prototypes. That’s where the accessibility aspects should be defined. Last time I did a talk at a conference was about the failure of UX and not thinking about accessibility during the design process. That’s one of the links are put in the notes. So, as an example of that. And this is a very basic sketch of the sort of corporate style homepage. And we can define the areas of the page in terms of landmarks, what, what the heading structure is some of the sort of main components on the page. You could even define what you think the keyboard focus, sort of order will be. And it’s, it’s better done at this earlier stage. I’ll bring up one example, and apologies I have no idea if the audio is actually going to work on this. But if you get to this website using the screen reader, and I’m using voiceover So it puts, what the screen reader is saying in that bottom part of the screen. And you get an idea of the layout, and you’re able to skip headings until you find what you want, when it’s built in and see if the audio works well. And landmarks menu. Name search, you are currently in search Wk heading level two popular on Gov. uk heading level two services of information. Heading level three link benefits. Heading level three link verbs that deaths marriages and care.

So whilst that sort of thing can be tacked on by developers towards the end of the process, you get a much more elegant result if it’s considered as part of the design process. And whilst I do try and move the thinking about accessibility further forward, my focus today is about guidelines and how you test accessibility. So there’s a few different methods, but actually they generally boil down to two. There’s testing with people. And there is testing some content against the guidelines, and you can use tools to either drive that testing process or support that process. And it’s also important to realise that testing with people in various ways, is where the guidelines came from originally. They were derived from aggregating real people’s experiences. So, overall, testing with people who have disabilities is pretty much the gold standard. It’s a bit more complex than standard usability testing, because of the various technologies people can use but it is well worth it. It’s great for prioritising issues. Learning how people do things getting buy in from stakeholders who can see how people struggle, and their struggles are often needless, but it is quite difficult to cover very much of a website or application, people simply can’t get through that many pages. When you taking people through scenarios. It also means you need a fairly finished product to test with some things can be tested quite early in the process. But with various access technologies you quite often need a at least a good sort of web prototype in order to test, and it does tend to push it towards the end of the process. And there’s essentially sitting down and testing with guidelines. So, on screen I’ve put a subset of the official guidelines that have been somewhat translated and made specific for an organisation. They do refer to the official international guidelines, but because the context of this organisation was known it was worth going through those guidelines and just translating them into how this organisation was going to apply them. It can be sped up using certain tools, but it is essentially a manual process to test pages in this way. Otherwise you’ll miss key things. So the downside is there is a reasonable level of knowledge needed about primarily web development but also accessibility in order to get good results for testing with the guidelines. And it’s something that can be applied fairly early in the process. So, we need to be careful this microphone. So, there are options for sending robots around an entire website or application, and generally these will be based on the weekend guidelines. Some tried to do more, including Best practices, but generally they are guideline checks. They’re great for getting coverage across the websites, but they will only find between about 30 and 50% of the issues on the site, and no tool can actually say that you pass, it can only say that you fail. That’s how the guidelines are set up because there are multiple ways of passing. But not every way of passing can be found by an automated test. So, we have a range of usability and accessibility issues that I’ve put sort of horizontally on the screen. and the vertical axis is essentially, ease of getting coverage across across a website. So, at the top we have usability testing with people with disabilities, which will get you a full range of usability and accessibility issues, but not necessarily across very much with the website usability testing with just standard in a general public population will often find a few accessibility issues as well. We do tend to find a sort of manual audit or guidelines review, whatever we call it is pretty good in terms of getting good coverage if you pick good sample pages, and it should find most of the sort of core accessibility issues. And then there’s automated testing can get great coverage but only for a few, or relatively few of the issues that should be should be found. So those are the different methods. Moving on to the guidelines, and when we talk about accessibility guidelines people usually mean, what can. I’ve also had it pronounced the way CAG or w CAG. I did the presentation. This is the slide that got the most comments from accessibility experts. So I thought it’s worth taking a moment for those who may not be aware of the workout workout guidelines, just say, Where did they come from. So the organisation they come from it’s called w three c formed by Tim berners Lee, the inventor of the web who has a sort of benevolent benevolent dictator status there.

And w three C sharp herbs with web standards like HTML and CSS, but also the accessibility guidelines, because right from the start, the vision was that this is for everyone. W three C is a membership organisation with large companies like Google, Microsoft, Apple and but also specialist organisations like Nomensa as well. Then back in the early days, thinking in the 90s. There were no accessibility guidelines for the web. So governments and policymakers wanting some method to assess accessibility were a bit stuck. There was a real danger that they would they that each country will come up with its own guidelines, so the W three c worked on this problem. And looking at the whole ecosystem. It’s worth realising that there are websites. There are the technologies that people use to access the websites, and then also the tools that people use to make websites. So originally the 33, he came up with three sets of guidelines. So, web content guidelines are probably the best known by quite a long way. Because there are millions, billions of websites, but relatively few user agents and authoring tools, and the success of standards, often comes down to how many different people and organisations are using them. So, to focus on the content guidelines. They became more important because testing with user agents became rather difficult, if we just think about the sort of regular browsers that people use, you think of the ones that come on screen so chrome Internet Explorer, Firefox, Safari, the mobile versions as well. can then consider people using access technologies. There are several screen readers, and each works with at least one browser, sometimes two or three, and you get different bugs and each combination. There are several popular screen magnifiers, which the book different levels of customization and reading aloud. There are many different input methods from Dragon’s completely voice activated activated method to switches that actors one button interfaces. So, we have a real plethora of possible user agents, all working in different ways. And this is a small selection of some of the most well known assistive technologies. Many of these also work together, which again can make the testing matrix, essentially many dimensional array and browser testing then looks easy by comparison. So we need an abstraction layer, we need a way to ensure that a website is doing its bit, without spending all the time in testing. When starting off. There were many sources of issues. So there’s usability testing as we’ve talked about. Experts experience was often coming from testing from personal experience from surveys from research, but they usually start off as a user requirements. So, now, a user with such and such disability needs to be able to do this thing. And that has to be transformed into a content requirement, and I’ll show you why. So, for example, most screen readers I used to navigate pages by headings, we link to that in the example earlier. so you can press a keyboard shortcuts, and it skips to the next one. So you might think you would want to create a guideline such as users can navigate navigate by headings and lists when appropriate. But basing a guideline on the desired behaviour, it’s easier to understand but it then requires you to know what users can do. You know it ups the level of accessibility knowledge required, it tends to be quite technology specific. So the same thing might not apply very well to other web technologies, apart from HTML. And it means you have to decide on what’s appropriate which when it comes to things like sort of governments and the legal side gets quite tricky. So the second approach on the slide is the official success criteria of information structure and relationships can be conveyed through presentation, can be programmatically determined, or available in text. It’s not as easy to understand, I will admit, but it is an awful lot easier to test. It’s essentially saying, for each thing on the page. Is it using the right structure. It’s also more stable, if new markup gets added to HTML, there’s no need to update this guideline, it automatically applies

to give a little overview of the actual guidelines, working to document itself, it’s organised into two levels of groupings at the top level we have principles perceivable operable understandable and robust. So there’s four principles within those four principles or 12 guidelines. Overall, not each. And then there are 38, success criteria at Level A or double A which i’ll come on to in a second. But when people talk about guidelines, they often actually mean the success criteria so it doesn’t meet a guideline, or the guidelines quite general, what you usually mean is a set is a success criteria, which is a testable statement about web content. You know, and one that is known to improve access for people with disabilities to give a little overview of the sort of levels that I’m sure most

people have heard of.

You might have heard, so Level A is essentially the sort of must do otherwise there are going to be barriers that are impossible to overcome for some people, level, a significant barriers, but there are often workarounds, and then sort of triple A level is useful useful to many possibly essential to a few, but often harder to do and that’s the general sort of rule of thumb, it’s not black and white but basically if it’s harder to overcome from the user’s point of view, it goes up those levels. And then if it’s harder for the organisation to implement it goes down those levels. Most organisations aim for sort of double A level. That’s what governments, usually in the West at least tend to require from government websites and the legal framework in a country will sort of dictate what level but level double A is often used as the baseline. So I just also wanted to point out an often missed link in in the guidelines, so there’s one of these understanding links for every single success criteria in the guidelines, and it is a final way the easiest thing to understand you click on that link, you go through to what’s called the understanding document, and that gives you an overview of what the guideline means what it should achieve and how to test it. So that’s a quick overview of the current work Hank. So it’s sort of what next well after about 10 years what CAG is getting an update. This has been a surprise to some people. And the question then comes up as to why. Well, most of our cake tea was written in roughly 2006, so touchscreens weren’t a consideration back then. That wasn’t an immediate problem, but after about 2010 touchscreens started becoming very mainstream JavaScript frameworks and single page applications have also become much more common, which brings their own concerns. And even when they were released. There were some notable gaps for people with cognitive issues or low vision, and just taking a little step back over the history of computing there have been several major changes that have led to big concern from people with accessibility requirements. In the beginning was the command line, and there were screen readers for it. When you think about how command lines work screen readers are actually very well suited to those because it’s a very linear flow, it can read line by line. And then the GUI was invented, or rather popularised in the 90s. And then, a lot of people using screen readers were really worried because how could a screen reader cope with all these different windows. But standards for the applications were invented and methods were found. When the iPhone was introduced. It was another odd moment because things which worked with the keyboard were no longer available. So, on screen I’ve got an old Nokia, and 95. My favourite phone at the time. And that you could get a screen reader for and the physical buttons enabled people who couldn’t see to get around. And then the iPhone was invented which was from their point of view, a flat screen with nothing to touch. But again, Apple introduced a touch interface based screen reader called voiceover and some other technologies and the iPhone is actually very highly regarded from an accessibility point of view, and androids certain, I’m not sure about catching up, but it’s certainly improving rapidly. In future, we’ll have new interfaces. You know, some things may not even be solid so I’ve got a little clip on screen of, sort of virtual reality, augmented reality sorry interface where somebody reaches out and grabs something which requires you know good vision good mobility and is probably not remotely accessible for some people at the moment. However, the principle of input output independence is very well established. I’m

pretty confident we can avoid the pitfalls, the same kind of things can be achieved by talking to a computer, and that sort of technology is coming on pretty rapidly at the moment. So, as our standards and guidelines lag behind the latest cutting edge interfaces. So I’m going to come back to earth and talk about the work act 2.1 update. So, it’s aiming to be a sort of evolution in the next year, and another one fairly soon after. To start that process, about three to four years ago. Several task forces were formed to invest investigate specific issues around mobile cognitive and low vision. And these Went, went away and lots of research, came back and transformed transformed the sort of user requirements have a finding into content requirements. And that was put into a first public Working Draft in February this year. And we’re going through a sort of monthly iteration process at the moment. At the end of August, we will have a stop on all new success criteria, guidelines. And then, those will be sort of iterated and worked on until January 2018, at which point that becomes what’s called a candidate recommendation, which is basically this thing will become the recommendation, which w three sees big means a standard. In June of 2018, we hope. So between candidates, and the actual launch is when people can object, and get things from record. So, there are many possible success criteria, but I cannot tell you at this stage, what will make it into the final guidelines. So what I’d like to do is give you a taste of what’s coming up, and what you can do with it. So, there were several new mobile criteria coming through. I think I had on the previous slide, there’s something like 60 potential new ones. But we’re only going to cover about 20, that are the most likely to get through. So, in the mobile category. There are several here which I’m going to go through one by one. The first is orientation, which is essentially saying, Please don’t block the display to a specific orientation, unless you really have to. And there’s a simple reason for that. If you can’t change the orientation of your device, you’re going to get some rather strange results. So it’s quite rare in a web point of view but there are ways that you can actually lock the orientation in a web browser. So I played around with did that with our own website, and you can get some very strange results with trying to read sideways is not ideal. And you might think, well, anyone can just turn it around but unfortunately not quite a lot of people with mobility impairments, simply can’t turn their device around so I’ve put on screen a picture of a gentleman who’s actually the CEO of a software company, but he’s quadriplegic is in a chair, and he has his phone, essentially sort of honest and in his chair, which he can use a switch access and you can use the voice access as well. One thing you can’t do is easily turn his phone around. And I’ll put a video in the notes. It’s his name’s Todd, and unfortunately I can’t remember his surname at the moment but I’ve got a link in the notes but. Another aspect is keyboard shortcuts, which is less about mobile access and more about voice input. So, where websites. Add keyboard shortcuts. I’ve got a screenshot of Gmail showing the help with all the keyboard shortcuts. It’s useful to either let people turn them off, or enable them to remap it to a shortcut of their choice. And the reason for this is sometimes voice inputs. Might automatically sort of pick up things people are saying, and then that gets translated through to these keyboard shortcuts so you might accidentally email someone, or it might interfere with other access technologies, so it’s very useful to be able to turn them off

target size is another one so if you imagine somebody using a phone, maybe with sort of moderate mobility impairments. It can be quite difficult to hit small touch targets on a screen. So, the 44 by 44. css pixels is derived from things like the iOS guidelines in the Android guidelines. And it does have quite a lot of exceptions, I have to say. And that’s because it is more difficult to implement on the web than it is in Apps at the moment. If I just share an example of applying this to Wikipedia. If you make sure every single link has that much space around it. It really does impact things like navigation menus and links within text as well. So there are several exceptions so that this kind of display isn’t actually needed. There’s also one about visible labels so that where you have a visible label. That is, at least part of the access accessible name. So I’ve got two examples on the screen one is from Google’s paginated search results. And it has I focused on the nine in the one to 10 pages, and the label or the accessible name for that control is page nine. So that one passes because nine is part of the label. I had to suddenly contrive an example that fails, so I took a Send button and gave it a label of submit, so the visible text is send, but somebody using voice input might say, click the Send button, and nothing would happen because the actual name under the hood is submit. So, it’s cool not to do that. Accidental activation is picking up on an issue that can actually be a usability issue as well where people who are scripting an interface might use events such as on key press or on mouse down. So, when you use a generic JavaScript event such as on click that will actually activate on the mouse up, not the mouse down. And that is something you would notice pretty quickly it can cause some usability issues which are even worse for some people with disabilities. So for example, if you were trying to scroll on a touch interface, you might accidentally follow a link by accident. So those are the most likely mobile ones to get through the new criteria for low vision or jumping around either making things bigger or improving the contrast. So, there is currently a working 2.0 success criteria for allowing people to zoom in to 100%. But since then, responsive web design has become much more popular. And it’s possible to zoom in to 400% fairly easily. Now, whether it’s 400% depends on the starting size of your window. So the way this one has been phrased is to say you should be able to zoom to an equivalent width of 320 CSS pixels. So that basically equates to a sort of small smartphone size. And I can give a quick demo of that. So we’re looking at the Boston Globe, this is the sort of full width desktop display. And if I start zooming in. We essentially get through to what most people think of as the mobile version so the loudness reflowed. The text is huge. This is far better for somebody with low vision, than simply expanding the text size. Some people will argue about that a little bit but overall, this level of reflow and making things bigger has been a big improvement for people who need to zoom in. So graphics contrast is plugging the hole, I would say, so we’ve had a text contrast in working to an end 2.1 we’re trying to introduce graphics contrast, so it’s applying the same sort of principle, but two graphics which are essential for understanding, and that’s a key phrase because it means, if it has text next to it, it’s not essential. If it’s decorative is not essential. So it’s, it doesn’t apply to everything by any means, it is really aimed at things like icons buttons and some things like sort of charts, as well. So, taking a quick example from the Microsoft home page. There’s actually only two elements in this screenshot, which is a little description is the Microsoft homepage, it’s got navigation and search at the top. We’ve got a carousel in the middle with a plain pause button at the bottom. So the only two elements that are graphical that are required for understanding, are the little trolley icon in the top right, and the plan pause button at the bottom left, and that’s because they don’t have text. At least text that describes what they are. So, black and white is very contrasting, but the thin, you know one pixel outline of a trolley in a light grey on white or medium grey on white doesn’t quite make the 4.5 to one guideline.

So, that, that one would fail and we’d be looking at either using a darker colour, or making a thicker. Now very closely related one is interactive controls contrast. So, the things which make a component look like a control. So, what makes this button, like a button, essentially, needs to have sufficient contrast. It sounds very similar to the previous one but it tends to apply to different elements on the page. And as a quick example. I stole this from Google’s material design. And it’s a blue button on a light grey background. So that’s got a 2.7 to one ratio. By default, which means that the button on the left would fail this guideline. The button in the middle is actually not applicable because it has no outline. There’s nothing that actually says this is a button, apart from the text. So from the point of view this guideline is not applicable. And the version on the right, I manually darkened, just to get it above the 3.3 to one contrast ratio. So that does still fail takes contrast unless we increase the text size, but it’s just a little sort of example to say, you know, if a. If an interactive control has things in it which make it look like a control those need to have sufficient contrast. Last one from Blue vision, Task Force is adaptable text, which is essentially running a where the user would run something on their browser that adapts the text on the page. So it’s not something that website is providing. This is just saying that if the user does this website should be able to cope with it. So, the kinds of things are increasing the letter and Word Spacing line height and paragraph spacing. Changing the colour and font family are also being discussed. They’re not in there at the moment purely because we haven’t found a very good way of specifying how that would work. So, the others are fairly easy to test. I’ll do a quick example, taking BBC homepage. And this when I run the scripts on it, which does the colour and font family as well. It ranks, very well to the spacing that doesn’t cause me a problem because there are no fixed height elements. However, when we change the font family you’ll notice that the weather icons, I’ll get that just for a second. So we’ve got weather icons in the top right, because those are done with a font embedding method to put the icons in, they disappear because if the user overrides the font family that character in the user’s font, probably doesn’t have an equivalent and if it did, it wouldn’t be the same as the icon specified on the website. Some of the other images like the BBC One, and the search icon are fine because they’re SVG elements. So that’s one of the sort of proposed techniques for this would be to use those instead of font embedding techniques. On the cognitive side, there were many many proposed success criteria. And I have to admit they are the hardest ones to get in, they overlap most with usability, which makes them sort of more of a grey area. They also tend to require more from the website, which makes them harder to sort of get into the workout framework. However, three are in the current draft, so I’ll just run through those quickly. One is interruptions, which is where a website will interrupt you, whether it’s for a timeout could also relate to advertising. It should give you the ability to suppress those interruptions, they can have a huge impact on people with cognitive issues such as dementia. So it’s providing the user an ability to either bypass or postpone them. Another one is authentication. So, anything which requires people to memorise things can be very problematic and passwords are obviously one of the most problematic areas for that. So, the ideal would be for organisations to provide alternative login methods, especially on the sort of hardware side.

But one of the sort of easier fallbacks is a, an easy reset process. And we’ve heard from a few people with cognitive issues that will just use that every time they don’t even bother trying to remember a password that will just reset it. Every time you want to log in. There were several sort of content requirements that come from wanting to enable personalization. And one of those is essentially allowing people to understand conventional controls more easily. Now there’s a few ways that might happen so depending on what the website does and what the user has it might be that it automatically adds icons. So, if you have name as a field that might have a particular icon that the users familiar with it’s not something that website provides. And the way this has been proposed is to specify a set of around certainty convention or controls. So some of these are for form fields sitemap for navigation like home and sitemap. And some of them are for buttons that you might get in editors, like bolding and italics.

So, just as a sort of quick demo. This was put together by somebody just purely to break it, but purely to demonstrate how it would work so at the top we’ve got quite a few options in the navigation, we’ve got a Contact Us form, and then the idea is that applying a script from the user side would then, in this case, reduce the options in the main menu. That’s not carrying the guideline yet, but it’s allowed the metadata applied has allowed icons to be added to home sitemap, and the submit button as well. So that’s the general idea this is just on the sort of edge of getting into the guidelines draft at the moment. So those are the ones which we’re heading into the draft at the moment. There are a few other ones I will just note that are sort of on the list of things that could get in but we’re not sure yet. So one is allowing users to turn off animations, from things like scrolling so scrolling itself is a kind of animation. But when you add more on top of that, such as parallax effects that can really affect people with vestibular issues. So, it can cause nausea, and headaches and things like that it’s a it’s a little bit like a sort of epilepsy trigger almost in that it can suddenly affect someone through things like parallax scrolling, or, you know, full screen animations. And, you know, they had to go down and lie down for three hours to recover. So it’s quite severe when it does affect people. And there is a new media query coming in that will allow people to set a preference for not wanting that. So, other guy, other potential success criteria sorry, catch myself saying guidelines. notify notify users when something changes on the page. So there’s this oddly no current guideline for that. So people who you know might add something to the basket, get notification about that. A couple from cognitive forms automatically correcting errors when that’s possible, providing an undo if you’re going through a step process comprehension support for long document. So things like adding an abstract or some kind of visual graphic to go with it. And from the mobile. Don’t rely on special pointers, such as styluses. When you’re taking input. So nothing wrong with using those sorts of inputs. It’s just a matter of not that not being the only way of doing input. So, what to do with all of this, and I’m gonna make the point again that big companies like Microsoft, Google and Apple. See accessibility and inclusive design as a commercial advantage. They’re all committed to building in accessibility across their platforms, they aren’t always perfect, but actually it has changed a lot in the last five to 10 years as they have started competing on accessibility, and it, it is a commercial thing it’s not, you know, out of the goodness of their heart. Maybe it is but I think it is also a commercial advantage that they recognise. So, if you’re in an organisation and wondering what to do with all of this. Here’s what I would recommend as a sort of, you know, quickly get your organisation up to speed and accessibility. And I would say, unless you have people in the organisation that are pretty experienced in accessibility. It is worth getting training, just to make sure that sort of team understand that. Well essentially gets onto the same sort of page about accessibility. So they understand the sort of core requirements and know enough to recognise when problems are coming out the guidelines are a really useful shortcuts to help play inclusive design because they they sort of point out all the things that you might forget. But I wouldn’t sort of, you know, necessarily just print out the guidelines and and go through those. And I would work out. When, when they do apply in your process, and who should know about them as you go through. So you might have some that are more orientated towards design some that are more development orientated do be aware, you need to sort of think about them as early as possible in the process. And one way of actually doing that is to check over things like brand guidelines pattern libraries.

If you have any sort of code libraries, any of the common resources that your organisation uses should be accessible by default. Because if you don’t go through that process. You’re just going to continue trying to fix the same issues, again and again. I also do recommend testing, little and often, especially compared to leaving it to the end. It will be the hardest, it will ever be the first time that you that you do test for accessibility. But it gets easier each time. And when you run into issues, see whether you cannot take your processes or resources for next time, and try and visualise that a little bit. I just put together a sort of little diagram showing a project overview at the bottom going from discovery through low fidelity design development and sort of QA and launch. And, and I sort of company accessibility guidelines at the top. And I say company accessibility so it’s somebody who played with reasonable accessibility knowledge, going through the guidelines workout when they’re playing your process, feeding those through to the design patterns feeding them through to the code libraries. And then at the end. Ideally at any point through the process but definitely towards the end of the project, feeding back into those guidelines, you know where were things difficult what can we improve next time. One example of a company doing this is eBay’s mind pattern library, which I think is messaging input navigation and disclosure but it’s essentially a pattern library. It outlines each and sort of pattern, including a visual representation of it, but it also goes through all the accessibility aspects of it as well. So making sure that anyone coming to this can lift the code out and apply it in an accessible way. If you have already got all that in place, and you’re really looking forward to the new guidelines, go and have a look. They are published, I think there is a more up to date one since the Third of May, which is on screen, but the URL will be static, and I’ve got that in the notes as well. So please don’t do go and have a look. The new ones are highlighted. And if you read the introduction that will show you how to find them. And these are public and the comments are public as well. So please do do go through to say GitHub. If you find the guideline you can get straight through to that particular guideline. And please, you know put in a bug. If you think something can be improved. If something’s not feasible, whatever feedback you have, if you think it’s a great idea. That’s also useful to know as well. So, this will be open certainly toward the end of the year. In terms of, you can sort of make any comment through to the end of the year in the new year.

I think it will be a question of refining down because we’ll be going into that sort of final draft process. I’m part of that working group, you’ll see many comments from me that I think my face is a tiny little thing in that screenshot. So, yeah, please do comment, I managed three of the success criteria at the moment. So, we are open for comments. So with that, I will say, thank you very much. And done. Does anyone have any questions, he says looking as colleague, no questions now I’m going to open the control panel and see if anything’s coming through. Yes, there’ll be a recording of this. And we will caption it as well, because we didn’t have the wherewithal to caption it live.

Is there something about minimum font size to use not only for contrast but to guarantee readability. And minimum font size is quite a difficult thing to do to define on the lab. It seems really obvious. However, especially in responsive design, things get different very quickly. So the general idea is that you can adapt things. And what the guideline does is set a, a sort of maximum amount of adaptability that you should cater for. So, in the new guideline, it will be 400%. If you’re starting at pixel widescreen. And the idea is that 99% of websites are going to have a font size that is readable by people with normal efficient. So, it’s only really when you would be doing tiny texts that a lot of people would have would struggle with that you’re then going to struggle at 400%. And there are other things that users can do to increase beyond that point as well. But that will probably be in the next version of the guidelines. How to get the 20% off for the UX and design conference. So if we have your name so if you just get in touch with our team, he says looking at temporary hoping to get an answer to that event, events, mentor.com. Is there a conflict between the new cognitive success criteria interruptions and the existing criteria provide enough time. No, that is something that will be looked at very carefully. I believe the existing criteria. Doesn’t essentially account for interrupting people partway through that time. So the new criteria is more around, not interrupting people. Is there a plan to create similar guidelines around mobile applications and not from the W three C, because they would see the remit as web content. Now, there is overlap. So, there is web content that gets embedded in mobile apps as well. And also, I would recommend looking up the BBC mobile accessibility guidelines. You may have come across some already. But that was a very good exercise in applying the sort of known principles from work ag to properly working and elsewhere actually to mobile applications as well. And that that is very much the sort of BBC is here how we do things, how we do things. But because they’re, they have such a public remit, that’s quite useful for most people. Do you have any advice for setting up user testing with people with accessibility needs. And that is a good and very big question that is probably worth a whole webinar in itself as a top line. If you already do usability testing. It’s sort of similar in process, but there are several things different so recruitment. You need to be careful, sort of, how you’re recruiting, making sure people can get digital copies of things they might be asked to sign, and potentially large print.

Also, we generally recommend allowing people to bring their own technology in. So if they have a laptop,

adjusting your usability setup so that people can sort of just put their laptop laptop down, and then you come up with some way of monitoring their screen screen and audio. So, otherwise essentially you spend a lot of time faffing around getting people set up on your computer. Which is, is suboptimal for a couple of reasons. And some people with sort of either low vision or other sort of custom setups around windows themes will quite often have it, have their own sort of computer or laptop set up. And they actually don’t know how to set it up it, they either did it themselves a long time ago or somebody else helped them. And that is their setup and they’re sticking with it. So, getting people to then come in and help you set it up is counterproductive. So, yeah, my advice would be get people to bring their own technology, and then you work out how to record it.

Have you prepared for your workout call in nine minutes. No pass. Can I plead the fifth on that one. Is there a cheap version of screen reading software to use for testing I

can’t convince my boss to pay for drawers. Yes Get NVDA, and use that with Firefox. That is the free one but please do contribute, when it asks you to. It’s a voluntary thing but there’s only a few people behind that. So, they need the contributions to keep going. But it’s yeah jaws is probably still the sort of market leading one, or most used one in terms of usage last time I saw the steps. But NVDA is pretty much on a par when it comes to testing websites. Do you see the value of obtaining formal accreditation for accessibility, or should it be seen as something that’s done by default.

Some clients often public sector see accreditation as a big thing. The only accreditation I’m aware of is from the International

Association of accessibility professionals. There is an initial sort of accessibility, like this. I’m going to get the terminology wrong. There’s a basic module that is kind of the accessibility overview. And it’s you know what laws are there around the around the world and that sort of thing is not specific to web accessibility yet, although that is being worked on. I don’t know about formal, I don’t know how useful formal accreditation is I would say there isn’t very much of that yet. But I would say that training is really important because to be honest, there’s a lot of myths around that people seem to get stuck in, so having an official training session, we do provide those as to other people, is really a good way of getting the team on the same page. How do you prioritise issues that you find in user testing studies with people with disabilities eg. a usability issue which may not be included in what CAG but causes big issues for visually impaired user, for example, I would prioritise the same way we prioritise sort of usability testing issues in general, which is how big an impact. Did it have on that journey, and how important is it to the organisation that that is not a barrier. So I’m assuming you mean that these were causing issues for people with visual impairments, but not other people. But I would tend to sort of prioritise it in a similar way to UX. The example I would use is, if somebody can’t select the date picker on a holiday site, which is usually on the first page. That’s a huge issue, if people can’t read the old text or there’s old text missing from a Lego in the footer, that probably doesn’t affect very many people at all. So I tend to just treat anything as a barrier, as a barrier, and then prioritise on importance of the journey. And I think that’s the last one. Any others from Twitter. No, well thank you for reminding me I have a workout call in four minutes, just scanning through the questions I missed. Conventional control slide, are the examples agents like screenshot good examples to meet should emulate.

Those are two quite different examples so the slank one was basically a. Just saying. Email authentication, or email, sort of, password reset is perfectly reasonable. And then the example about conventional controls. The, the only aspect. In this demo to focus on is the main code main gets transformed to home with an icon. So the way that would be achieved would be through either metadata, or making sure that the accessible name of that control matches the conventional control in the list.

And now I think my voice is going. So, coming up to the end of our hour. And thank you, Gemma for saying thank you. Yeah, so thank you very much. Everyone, please do go to that link. If you want any of the links from today’s presentation. And that’s also got my contact details on if you need it. Right.