Accessibility and Mobile Testing Tools

Video Transcript

0:00 | Helen Burge
Hello, and welcome to this talk on accessibility and mobile testing tools. My name is Helen Burge and I’m the Director of Digital Accessibility at Testneo. So in this session, we aim to cover meeting me, your speaker, what accessibility is the mobile tools for testing accessibility as a starting point and the questions you might have at the end? So, my credentials, I always believe when talking to any group, I should share why I’m qualified. So I’m qualified to talk on accessibility and mobile because I’ve started working accessibility since 2000, I was at university, it was my gap year and I was doing ADA testing on some CRM content relationship management systems. But the main reason why I started testing accessibility was because of a friend that was blind, She couldn’t get her.

0:58 | Helen Burge
Keyboard to focus her music player. So she had to ask me to be the tool to start her music. And it was such a simple thing that stopped her from enjoying her own music and being able to be autonomous on her own. That made me realize that small changes can make a big difference to humans. Anyway. As part of my journey, I started doing other testing and doing accessibility at something as well as my main role of testing functional tester, performance tester, automation so on. But in 2010, I realized that my passion of accessibility could be a full time job and I managed to make it work. I also volunteered with the WC as part of the accessibility conformance test rules community group. And from my work there where we are trying to… make the success criterion that I’ll go through later into automated rules that can be agreed upon by different automation tool vendors. The work I’ve been doing on the manual test rules side is seen as important. So I’m now an official invited expert to the WQC And I’ve also in my journey as an accessibility auditor also tested mobile, whether it was native applications or web applications. I always felt that because it’s a digital asset, the web content part of WCAG is not always truly the only way that you can use them. They do apply to mobile. So I’ve been doing that practically for years. So what is accessibility? I’ve talked a lot about it… But I think we should cover the definition of accessible. So on this slide, you might be able to see an image of what I describe as a narrow street with overhanging buildings. And there’s some bikes parked at the back And you can see someone on their moped about to drive down there. So can you walk down it? I believe it’s possible to walk down, You might be a bit nervous of the narrowness, but it is possible to walk down. Can you take a bike down there? I think the answer is in the picture of the person about to drive down there. So yes, you can take a bike down there. And also the parked bikes have obviously traveled down there to get there. But would a car fit? Someone did say they thought a smart car might fit down here, but I think the smart car would be… become less smart and more of half a car And you might get a bit of a sore head from the collision. So the car would not fit. And this visual representation is how it is for most people interacting with your digital assets. Fine Being disabled is not the same as having an impairment. It is about the environment creating a barrier that you cannot use it. So each of the people are either walking using a bike or using the car, They have different tools that they’re using to move themselves better. However the one choosing to use a car has a barrier that they can’t undo, You can’t move the buildings apart. So a car driver through no fault of their own is blocked from using the street.

4:50 | Helen Burge
And this is the same for accessibility, where people are, they have a physical disability and they use assistive technology to interact with digital assets. But because the digital asset is not accessible, the assistive technology will not work. So that means they are blocked from having the same experience. And there’s many benefits to accessibility. So, the biggest one from the World Health Organization have done some studies And in 2016, 15 percent of the world’s population were classed as disabled. 15 percent. It’s about 1,000,000,000 people. You may not have a digital asset for everybody in the world. But when you think about 15 percent that you are excluding from using your digital asset.

5:48 | Helen Burge
You’re excluding part of your audience. And another thing is when people require assistive technology, when things work well or don’t work, they will tell each other. So I have a Slack group that I’m a member of an accessibility Slack group and they have a rant and a wins channel where they will share their frustrations in rant and their successes in wins. And other people will read that and will be swayed away from the rent products from using them and into the WINS products because they’re doing something good and proactive for disabled users. So the larger audience is also not just those with a disability, but those that know people affected by disability because if say my mother was excluded from using… a product because of her need for glasses. I also happen to need, I would choose not to use that product. Also accessibility drives innovation and increases engagement. So the innovation when you think about the car driver on that street on the slide before they would have to think of an alternative to get to the other end of the street. And that is innovation. It’s when you’re challenged to think differently, to find solutions for all the users. Because like I said, before, you cannot move those buildings apart. You have to think about an alternative route and also increase engagement. So if you think about captions, When you’re watching a video on Facebook and you’re in a public place, are you likely to have the volume up or the captions on? I tend to have the captions on. So that gives increased engagement because people are less likely to be put off from engaging… with your content. And it’s well known that there’s many times on your mobile, you do not want people outside of your inner circle to hear what you’re doing. Like for instance, sleeping children, you want them to stay sleeping, Or if you’re Watching something a bit more adult than your children, then you might put the captions on so that they don’t hear anything you don’t want them to. And there has been a few statistics banded about, but 80 percent of people are more likely to watch video all the way through if it has captions. So accessibility benefits everyone. It’s not just about people that are permanently disabled. So when you look at this image on this slide, you’ve got the Microsoft.

8:42 | Helen Burge
Inclusive design toolkit which shows permanent, temporary and situational impairments. So, permanent is something that will not change. So, for instance, hearing, when you’re deaf, you’ll never hear But you might have an ear infection, which means your hearing is not quite as good, But you should hopefully recover from that ear infection app or a bartender who in the situation of a noisy bar cannot hear things. So, in those cases, you might have an application where you can order drinks through your mobile app, which means the bartender doesn’t have to hear an order and they’ll more likely get your order correct. And there’s other situations too. I often think of myself, when I first get up in the morning, my understanding of items is a little bit more cloudy because I need a bit of coffee. So before coffee, an accessible site which is easy to see, easy to read, easy to follow is less likely to be a burden to me. And I know that everyone has moments when accessibility will benefit you. And if you want to go and get the design toolkit, if you go to microsoft com design, inclusive, you’ll be able to access those designs anyway, Web Content, Accessibility Guidelines, a brief history So created by the WCC and we can see their logo there. Wcc, the World Wide Web Consortium. And the first guidelines were both, in 1995 after a keynote speech at a conference in 1994 highlighted the need for accessibility. However, this meant 38 versions of guidelines were published. Thank you. Can you imagine trying to find one that you can follow when there’s so much, different opinions on what is accessible? So, in 1998, three years later, they unified these versions into the unified website accessibility guidelines. And May 1999 literally 25 years ago, fifth of May 1999. The World Wide Web Consortium released WCAG one. And it was a group consensus of web standards that people from different companies, different, groups affected by accessibility. So you might have, the Koga group, the cognitive, operator, I forget what it stands for, but the Koga group is about the neurodiverse people. Then you’ve also got people that are representing… blind users and so on, They came to a consensus of these checkpoints. And in the background, over the next nine years, an independent group was updating them because two years after the publication of the first WCAG release, WCAG two was suggested and it took seven, almost eight years before it was published in December, 2008. Again, it’s getting the consensus that can cause some of the confusion because they need to be repeatable and testable. Items trying to remove the subjectivity which is very difficult and accessibility. So, International Organization for Standardization recognized them four years after they were published and Europe recognized them six years after they were published. And then, because in 2008, the first iPhone hadn’t been released with a screen reader yet, It was 2009. When that happened, WCAG two was disappointed. So two point one, almost 10 years after the first WCAG two was published, we had two point one release. It was very exciting because it had mobile and neurodiverse checkpoints added in. So for the mobile, we had orientation and actuation where you’re shaking your phone because I keep being told you shouldn’t shake your laptop, Helen. So that was quite exciting. Took 10 years though. That’s how much discussion was going into it. And in 20 23 last year, two point two was published. So five years after the two point one update, we had another one, It was more about neurodiverse conditions or neurodivergent like accessible organizations, authentication, meaning that you can log in more than one way That includes copy and paste And WCAG three is in development. The good news about it is web content is going to be replaced by W3C. So it’s going to be WCAG still, but it’s going to be WCAC accessibility guidelines because digital assets will cover things like documentation, authoring, tools, all the different items that should be accessible because they’re used by the public will come under the AG or the silver group as it’s called. So, WCAG in a nutshell, We’re on two point two. At the moment, It is a WC recommendation. It has three levels. It’s got a double A and triple AA is the top of a pyramid with double A followed by triple A. We target double A which includes A and double A. Because that is the legal standard for most countries. When I say we, I’m talking about accessibility as a whole and test layer as well. We target what is legally required for the A and double A. Triple A is a nice to have but is not going to be enforced fully because it’s quite difficult and more subjective than the other ones. It’s also got four principles. We’ve got perceivable, operable, understandable and robust Perceivable is, do I rely on one sense to understand the content? Do I have to see it to know what’s going on? Do I have to hear it? And so on? Operable, if I can use the mouse, can I use the keyboard? Understandable? Is the language clear? Are the form controls given meaningful errors and so on And robust that, is it sticking to the… guidance given for HTML five and ARIA, the accessible rich internet applications coding standards that the WC provide That’s basically are you doing as a best practice? The recommended items. And when it comes to backward compatibility, All WCAG two is built on with two point one, then two point two, which means that two point two is backward compatible with two point one and two. And we have a WCAG quick reference by the W3 C. And also WCAG. The other way that some people pronounce it, I do WCAG, WCAG tends to be a simplified version of the checklist for developers in mind. So on to mobile tools for testing accessibility. So now, you know a bit the surface of what accessibility… is and what WCAG means. Now it comes to testing, Like I say, although there are original desktop in mind, you can apply it to native applications and to web apps on the mobile because they are interchangeable. Is, So we have the first thing screen readers, It’s a program that will read visible content for those that might not read it easily, including blind, visually impaired, or those that find reading difficult. So we have an image here of voiceover is turned on. We can see that voiceover on is what’s been announced by the screen reader. And it’s focusing on a button accessibility. So ideally is What it includes is the semantics. So if I’m on accessibility button, I will hear accessibility comma button. I don’t want that button in a label. What I want is the roll button so that when I interact with, it does what a button should do as in, with the screen reader on double tap, it moves back. It also, it just includes information that’s not rendered and can be a developer’s best friend or worst nightmare because it will quickly show when a developer has followed the best practices for the robust rule or when they have maybe neglected it. And then items might not be focusable, They might not work because they’ve not been following the best practices. And when it comes to screen readers to use, you’ve got iOS VoiceOver and Android, TalkBack. Those are the most commonly used in the market. And keyboard, A keyboard is one that’s often overlooked. And that is because when it comes to interacting.

18:22 | Helen Burge
On a mobile, you often think of your hands, your gestures. And with a screen reader, you have slightly different gestures which means people assume that keyboard will be covered but that’s not really the case. And it’s not often covered by testing. And I used to in my younger days not to cover keyboard but Bluetooth keyboard is different from the keyboard on your desktop because that will be a tab interface where you interact by the tab key and then enter in space depending However Bluetooth keyboard you can tap through and, or use the arrow keys. So you need to make sure that you’re using the content appropriately. And it’s also an easier starting point for switch testing. A switch device is used by someone who may not be able to use the hand gestures that well and will have it often looks like two buttons, but it’s… edges of buttons side of buttons. And I recommend with switch testing to leave it until you know a bit more about the Bluetooth testing. So start off with Bluetooth testing with the keyboard. And when you come to switch testing use a Bluetooth keyboard because using facial gestures without an actual switch device for switch testing, I almost had to do a factory reset on my phone because I had to look one way to select things and another way to activate them. It was painful. So I recommend if you’re going to do any switch testing, read up on how it works and make sure you’ve got a Bluetooth keyboard to map all the gestures to. And then we’ve got color contrast. I have the TPGI tool here of the color contrast analyzer. Now, I recommend either use a screenshot on your phone or the automation tools. The automation tools can catch most of them but some of them are like… Sometimes there’s a slight discoloration of the valid hex code on the actual screen. So what we see is not what’s programmed in. So screenshot’s the best way to validate them at the end. But use an automation tool for a starting point For mobile. There is three checks that you should be thinking about. Normally, there is three to one for large text or items on there. It’s better to go for the regular text four point five to one for mobile. Because you have a smaller screen, Large text and barely visible outlines are going to be very difficult. And that’s why it’s also recommended in the mobile groups to use the enhanced AAA requirement of seven to one. Because if I’m out with my mobile and it’s a sunny day, A stronger contrast. Like here, we’ve got black and white which is 21. To one, a stronger… contrast is easier to read. Things close to four point five or less will be difficult to read in sunny conditions. And then we’ve got Zoom. So one of the checkpoints for WCAG, two point two is about Zoom Being able to Zoom the application. And it’s often overlooked by mobile developers as something that should be possible because others don’t do it contrast. It doesn’t make it right? Because unfortunately, the checkpoint does say you should be able to zoom in without the need for assistive technology. And mobile applications do come under the user agent accessibility guidelines where you should allow the person to zoom. So there are two different sets of guidelines telling you zoom should be allowed. And this could be done by using pinch screen. There are ways to force a zoom on some operating systems, but those are kind of overriding and are not the best practices. And also you can end up with lots of variations of items to code for. So I tend to stick to pinch screen for the zoom you might have in a browser. And changing the font size in the operating system level, Changing the font size is probably the better one to do than the pinch zoom because that’s very much like the magnifier and are not the best options. But then again, it’s easier to fit it in because you scroll around Anyway, try to make sure zooming works. Then we have automation On iOS. We’ve got Xcode Accessibility Inspector which you launch by having your iPhone paired to your Mac And you can run through the application as it’s running on your phone. And you find the results where it will let you know the code failures. The Google Accessibility Scanner for Android, it will download onto your phone. So you don’t need to pair it with a device And it will let you know when you’re not meeting the accessibility guidelines. So one of the important ones that I always say is best done with automation is touch target size. And Kobiton adds an option for testing touch target size. This was something proposed as a level eight for two point one. However the 44 by 44 CS pixels was very hard to achieve and they couldn’t get to an agreement. It was agreed at the end to push it down to a triple A because of the difficulty in trying to have large buttons on say a mobile device Or what if you got a paragraph of text with three links in it, You’ll end up lots of situations where it doesn’t work. However in two point two, they reduced it to 24 by 24 CSS pixels. And it’s a level double A And it’s the touch size… of the button and the area around it. There are exceptions like if it’s inline or if there’s an equivalent, a different button elsewhere that has the right size, But overall try to stick to 44 by 44 if you can. Because. And also because it’s not easy to see the touch area, you can’t see where the items around it are. It’s hard to test manually and I recommend using a tool to help. And Kobiton also has an accessibility application programming interface check which is like with the automation tools where it highlights what’s at fault and it helps you setting up what items you want to set in. So it will check that you’re meeting the success criterion. It will optimize and let you change items for text speech and Braille, so that it can be more accessible. And also you also have a way to make your labels more precise. So to summarize accessibility is for everyone, This talk is just a starting point. I didn’t go through as much as I could have and I kept having to bite my tongue to stop going into too much detail. There’s so much on this subject. The guidelines will apply to mobile even if they’re not explicitly called out because some of it’s just common sense. Like if it’s an image, I should have a text alternative to it. Testing with mobile devices should be manual and automation. I don’t think either or will work fully. They go really well together. And lastly, happy Global Accessibility Awareness Day. Gad, it is today And thank you for attending this session. Any questions?

26:07 | Adam Creamer
All right. Thank you for that, Helen. And thank you for joining us for some questions here. At the end, You mentioned it at the end of your session that today is actually Global Accessibility Awareness Day. And I was hoping you could expand a little bit on that, what the day is and how people can help spread awareness.

26:25 | Helen Burge
Sure. It was the thirteenth or today’s the thirteenth year of Global Accessibility Awareness Day. And it was a day brought about to champion accessibility as a starting point to get people thinking and incorporating accessibility to their work. So attending talks on this day is greatly encouraged. And everyone who’s watched this video has helped celebrate in their own way.

26:52 | Adam Creamer
Excellent. Yeah. I know it seems like in the last year, and rightfully so accessibility has kind of had its moment especially in the tech world. So for those of us in the audience watching this live, what do you have suggestions for them as far as getting started? Or is there something you would recommend if they’re looking to make their apps more accessible on specifically on mobile devices?

27:18 | Helen Burge
I think the starting point is making sure that you don’t try to reinvent the wheel, Most of the times when things are inaccessible. It’s when someone’s tried to build a custom item when the default has accessibility baked in. And also colors Colors are the biggest downfall for most people when they have weak color contrast, which means it’s hard for anyone to read. And on a mobile screen, when you think about the fact that mobile moves so much, actually, you catch sunlight… on it, You need stronger text to be able to read it properly in sunlight or different. Varying. Basically, the mobile is never in a fixed position And we’re not often talking with it to our ears, but talking with it in front of us and so on. So making sure that you don’t over complicate keep things clean and simple And if in doubt use an automation tool to help check it and maybe look into the WC about any resources that are available to help you.

28:37 | Adam Creamer
Yeah, absolutely. Yeah. And I know you touched on a few of those during your session as well. And I think it’s one of those things like we all use mobile devices. They’re so ingrained into daily life now and making sure that any user has the ability to pick it up and leverage the applications that folks here are building themselves is crucial. I know we’re coming up on time here, but is there any parting words you have for the audience before we head off to the next session?

29:03 | Helen Burge
No, thank you for coming. And I hope it was enlightening.

29:07 | Adam Creamer
Excellent. Thank you so much, Helen. It’s always a pleasure talking with you Cheers.