Accessibility Testing- tools - Part 2

Now we come to the third um um product that we spoke about which is Lighthouse. So what it does is it's a built into Chrome tool that audits your page uh in 30 seconds across five categories. So it it audits uh the accessibility performance best practices SEO and PWA. So accessibility score is of between 0 to 10 tests 30 plus rules from axore engine weighted scoring based on severity. Why it's powerful? So it's no installation needed built into chrome dev tools creates competitive pressure right. So uh our score is 68 competitor is 91 and a lot of uh benchmarking uh in GIGW or ACT are also placed around that if the score is 90 above then it is considered uh reasonably accessible and all of those things integrates with CI/CD pipelines. Lighthouse CI can block bad deployments. Also, the catch only tests the initial page load. So, misses on a lot of dynamic content. If your if your website or your app carries a lot of dynamic content, maybe this tool is not the best uh for you. So the first step in every accessibility audit can be this um because um it you know just gives you a good starting point just with the score you'll be able to uh kind of understand that okay I need to work at least this much to achieve a score which is above 90 95 and that is the good score. If I am somewhere around 60 then I should use all the tools available in the market in order to get to the core of all the accessibility issues. But am I better than the wave tool that we'll come to. Uh so how it is basically um you know doing that testing and labeling is like it gives you these scores. It's a nice dashboard and under each you can kind of get an idea. So it gives it tells you about performance metrics. So first content full paint. So initial content visibility uh speed index visual load speed content pane main content loads and total blocking time. the page responsiveness and everything and visual stability. So like cumulative layout, right? So all of these are important points. Accessibility checks it is able to do is you know color contrast ratios, area attributes and form labels, heading hierarchy and all text. It is able to label all of those things. So you what you can do is run it three four times actually average scores and um you know use incognito mode fix the red and orange issues first. Now we come to your um you know fifth uh fourth pillar which is your keyboard testing. So it's a um let's do like a reality check. So the challenge is let what maybe we we can do a small exercise. So maybe unplug your uh mouse or if you are working on a laptop just switch off your uh mouse pad and uh navigate your entire site with uh tab shift tab enter space s escape and arrow keys. Just try to do that. Take take uh five minutes maybe pause the video and uh take that five minutes turn off unplug your mouse turn off your uh laptop's um fingerpad and try to navigate this website uh with just tab shift tab enter and come back to this video on the same uh time time stamp you can pause the video and I'll still continue. Uh so let us continue. I hope you did experience something. You did try to do it and uh I'm sure you might have come across some issues. So one is invisible focus. It is very difficult to understand that where I am if you are doing navigating a website with tab you know I can't see where the cursor at the given moment is. Right? Then there's a keyboard trap. So if I am stuck in this model, I cannot escape. So if there is a drop-down or or if there is you go into inside a particular dashboard, then it is very difficult to come out. Then wrong tab order. So why did the focus jump from header to footer? I don't know. Or missing keyboard support. So this drop-down works with mouse but not uh keyboard. So the statistic says that there are millions of people who navigate web um uh only through keyboard and I mean we have stats from some reports from America but I'm sure there are stats from India as well. Uh so to tool the accessibility inside shows visual tab order overlay. So once you try to navigate it with just the keyboard, you'll be able to pinpoint all of these issues a little bit better. What we have to do is many a times also uh you know the keyboard tab uh architecture may be different from your visual architecture. And again I would refer you back to the book which is called mobile accessibility rituals. Then if you are talking particularly about um mobile apps and app design then mobile accessibility scanner which is again your inbuilt system is something which is most people kind of overlook primarily because it is there already on your phone. Uh so it's an accessibility scanner. It's a free Google app. You can just install it uh from play store. enable floating action button overlay. Navigate your app site, tap scan uh and you get instant results. So there can be some challenges which are unique to Android. Uh so minimum touch target uh has to be a 48x 48 dp. talk back gestures. So, swipe to navigate and all of those things um are there because you cannot uh it the system kind of relies on the fact that you're not able to uh visually interact with the screen. So, you have to have certain gestures to navigate. So instead of tab, it's actually a swipe on the talk back for the next word to be announced, the next button or whatever the action. So in the keyboard interaction is tap tap tap. But in your mobile interaction is swipe swipe. So maybe you can uh you can pause the video here uh as well and take take 5 minutes you you take your phone and you turn the accessibility scanner. Just download this app uh accessibility scanner app, install it on your phone and run it um and try to navigate any of your favorite uh app and just try to understand how it works. How it handles screen rotation is also very unique. Uh device fragmentation around the different manufacturers. So emulators miss the real bugs. So test on real devices. So uh many of times we may be while we are developing we are developing on actual you know PCs and we are developing the application uh and testing them u in an emulator right developing them in an emulator and so but testing them on the emulator may not be the right way to do rather uh you kind of export an APK install it on your phone and then test with your uh accessibility scanner app. So things which are which is it is able to find is touch targets. It is able to identify if it is too small for fingers. Uh low contrast text it is able to you know pinpoint missing labels on interactive elements. It is able to pinpoint uh clickable items are too close together. Maybe all of those things it is able to identify. So recording mode test entire user flow not just single screens. Okay. And um the gap may be that 60% mobile traffic and 20% uh you know testing effort is required. So what it means is that um if you are able to put in your 20% effort that may increase your mobile traffic by 60%. So please uh put in that effort. Then we come to the iOS accessibility testing. So there's something called the Xcode accessibility inspector. So uh you have to have a Mac and Xcode. Then if you have a Mac then Xcode is free. Uh what it what it tests is voice over uh announcement element labels and traits as well as focus order. So when you press tab or when you do swipe what is the order in which it is appearing? How to access? So Xcode open developer tool. You open Xcode you open developer tool. you um go to accessibility inspector and then just run your app. So it is able to identify um uh minimum touch target. The voice over uh gestures are swipe based. Safari and voice over required as a combo and 70% of the blind iOS users rely only on voice over as their talkback as their screen reader. So um I'm sure uh we are also we are also recording um a tutorial where we'll be talking about uh the mobile scanning uh app. So one is your uh this accessibility scanner uh of the Android as well as your Xcode accessibility inspector of the iOS. And we will be talking about both of these mobile accessibility scanning applications through more of a tutorial format. And uh you can see those sessions as well. Here in this session I am trying to kind of give you an idea of all what is existing and where in which situations you can use which tool. So now let us talk about the area labels and area coding. So when you u you know fix when your fix breaks everything right. So um for example some common disasters. So in your HTML code um if you your screen reader says submit button button button. So here what is happening is that you've already labeled a button area label equals to submit button and then it says submit/button. So it's reading all of those together and then the screen reader reads submit button button button. So just use the semantic HTML labeling first. The other is other disaster can be uh area hidden uh true mean button then it's by now looks perfect uh you know the screen reader button does not exist because you have not uh for the screen reader you have not uh added the area button label then here in this kind of scenario um it says it's a button But doesn't work like a button, right? So the right way is button click me button. So the number one source of accessibility bugs is use of these misuse of these area labels. And uh it is it is just important to understand and inform yourself about how to use um so so I mean it actually there is an official W3C rule uh which says no area is better than bad area. Now let us come to some other aspects. So we did talk about specialized analyzers in the beginning of this session and now we have kind of moved across all of those different kinds of accessibility evaluating evaluator tools. Now we will talk about your color analyzer tools for example. So, WCAD minimums are um you know for different kind of text different kind of uh for WCAD the minimum B uh thresholds for contrast have been defined. uh for normal text it is 4.5 is to 1 or 7 is to1 if it's aaa compliance for large text it is 3 is to 1 and for UI components also it's a minimum of 3 is to1 so your specialized tools for example so here it says so see normal text this is a normal text so it is has to be 4.5 to one larger text it can be lesser for bold text also it can be lesser for icons it can be 3 to1 and for UI elements like a button it has to be 3 is to one now so what we are here doing is button against the background so button contrast so UI elements means the border icon underline and the context so if the button contrast against the Background is 4.1 is to 1. Here it is passing. Here the text is also text against the background. White on teal it's passing. Here teal on gray it's passing. 4.5 is to one. Here it is uh you know in order to increase the uh contrast what we have done is we have used navy text and neon blue um button uh background. So here the ratio has largely increased. So it's very very tightly visible. Right? But here what is happening is that the button to background ratio this uh teal against this background is decreased. So it is now one is 1.1 is to 1 which is now failing. So now we have to see that how we can use all of this information in the best way possible. So maybe we increase the button uh the text size that will also uh uh involve increasing the button size a bit and we are saying okay the text is now 24 uh plus. So now our minimum limit is 3 is to 1 and now we put white on green and this green against gray is also 3 is to1. So we are passing in both formats. So what tool this color contrast analyzer which is also a free software it has eyroppers uh where you pick colors and you it tells you instant pass or fail. So you pick two combination so I pick I pick this and this it will tell me instantly whether it's a ratio pass or fail. So real student mistakes. So for example, designer picks um u number hash number seven triple 7 gray on white ratio um 4 uh 4.47 47 is to1 barely passes hard to read better another type of gray which is a darker gray ratio is much higher everyone can read comfortably so also you have to see that it's not barely passing right if it is 4.5 uh 4.5 is given it is 4.47 47 and it is not really passing built-in browser checks. So, Chrome Dave tools inspect you can open that and then you can put uh go to inspect text and you can see the contrast ratios live on your Chrome built-in browser check. The impact is that good contrast is equal to legal compliance, better user experience for millions of people with low vision. We have not even talked about uh you know low vision users because we're so engrossed with say sensory impairment but there are millions much more uh millions of people who have low vision or color blindness for that matter. So that is why uh it's um you know 4.5 is to 1 is a law and it's not really a suggestion. So we have to comply with this law. So color contrast uh you know how it is. So in a level at the top level the regular text at 16px has to be 7 is to 1. So this is an example of what 7 is to1 looks like. This is also an example of 7 is to1 at double A it is 4 4.5 is to 1 against this background these. So if you're seeing we are changing the background saturation the text is all white and that is what is changing the ratio. 3 is to1 is actually non-compliant for regular text. If it is bold or if it is icon or if it is more than 24 then you can use 3 to one. So please remember this. Then millions of people see colors differently. So they are color blind. So the there are like some uh very eyeopening statistics around color blindness which is like 8% of the males globally have color blindness and 300 million people globally have color blindness. So maybe you can just check it right away. Here it's an image from the Ishihara test. You can take that test also. You can just Google it. Uh the Ishihara test. This is one of the image. So just guess what number you are able to see. If you're able to see 74 probably you are not color blind. But if you're not able to see I would suggest please um take the Ishihara test and you will get to know if you have color blindness or not. And the point is that as developers we have to ensure that all our users and not so many millions of people get excluded because of incorrect use of colors. Right? So common failures which is so largely most common kind of color blindness is red green color blindness. So for example here the background here is red and there is a number written with green dots which is 74. If you are able to see it, great. If you're not able to see it, that's fine too. It's a very common u disability. But I think that kind of opens your eyes towards uh how common is it. And then red green indicator. So success is green, error is red, colorblind users, they all look the same. So if you have you know all of these dots which says uh you know red color is that something is going fine and the error says red and just small dots or some text appears for a colorblind user that's it looks the same or if you say uh you know color so I'm sure I mean this this very great example of this situation earlier till this is recent example so I'm sure you might have all seen those veg and non-veg dots which used to appear on all edible packaging. So earlier it was both of them were dots and they were just different colored dots green and red but if for a colorblind user both they look look the same. So how would they differentiate between wedge and non-veg? So eventually it was then changed to color as well as differentiation of shape. So now veg is like a green dot and non-veg is a red triangle. So even if you're color blind, you can rely on the shape differentiation. So for example, another common failure can be you click the blue button and there are four buttons which are different color, same size, same shape, no signifier or signifier is the text which is written. There's no text written and you just mentioned where you press the blue button. But which is the blue button? For a colorblind person, it may be difficult to identify. Uh then there may be charts with no labeling or uh just colors. Then that becomes almost unusable. So again testing tools can be your Dave tool uh rendering emulate vision deficiency. So there is this um drop-down already. So if you go to rendering uh and you select emulate vision deficiencies, it will give you a short report. Then Figma plug-in stark is a commonly used plug-in. Then there is another app called color oracle which can help you in identifying color blindness related issues on your product. So the fix is almost uh always never use color alone. use icons, use uh verbal labels or use patterns as well like dots and stripes also if it's like areas of colors. So after all of this we have come to the point that a complete testing strategy would be to use all of these tools in combination. So you in phase one you use automated scan you use lighthouse you use axe Dave tools you use wave and uh find out the technical violation. In phase two you you do your screen reader testing your keyboard testing all all of this manual testing which finds out your usability barriers. Then in phase three you do your user testing with real people with disabilities. then which may take you know one peak of time. So most teams they run automated tools and then ship. So but in that scenario you are only getting access or you're getting to know about only 30% of the problems and you're missing out on the remaining 70. But accessible teams they automate uh they use automated tools they use manual tools they use user testing and then they are able to find out all the 100% of the accessibility issues. So the final launch product is likely to be more accessible than the one where we are not employing all of these steps. So tools can only enable uh um you know facilitate accessibility identification but humans have to ensure it and this is where we'd like to close uh today's session. There's a lot of these tools which we have spoken about and I have added the link to all of them. You can go through at your own end and if you have questions we can answer them on the forum as well. And um uh they we have uh recorded one uh tutorial on the wave and the lighthouse tools which are your web based uh tools and we are all we've also u be um you know publishing another tutorial on the mobile accessibility valuation tools which is your voice over and talkback and I hope you get um you know access those tutorials as well and meanwhile please turn on all of these free tools. Please install them on your laptops. Please install them on your phones and uh explore these tools and uh a lot of it you will be able to identify and get a hang of yourself I'm sure. Uh so happy exploring and uh let's make uh you know products more accessible and please transfer this knowledge to your colleagues at work as well. Thank you for joining today's session. I will see you in the next.