 Hi, thank you everyone for coming. It's a pretty full house This is actually my first presentation in well in person presentation in over three years So bear with me. Thank you very much for coming And I want to talk a little bit. I usually present this to other accessibility specialists So I want to talk a little bit about Why I'm going to recommend that you use separate Accessibility guidelines to the web content accessibility guidelines. Does anyone here not know what the web content accessibility guidelines means? That's pretty good excellent. So my work here is done. See you later Okay, so we'll have to for those a little history if you're interested there is a history of web accessibility on the accessibility OZ website. I have been operating in web accessibility for 24 years So Thank you, and I actually spent six years with the W3C working on WCAG 2 and They were basically finished in 2004 to 2006 and we wanted to Make the WCAG success criteria applicable to everything, you know wall screens any kind of technology that we would see in the future and You know, we really hope there would not be a WCAG 3 guess what there's going to be a WCAG 3 Because in 2006 the iPhone hadn't been invented So we were testing, you know mobile phone websites on these little, you know Screens that were like black and white and took forever to load We had no concept of things like native apps and how we use technology today So yes, WCAG 2 is applicable to mobile, but there are a whole lot of things that Not included that are really important when it comes to mobile accessibility And so if anyone asks you well, why don't you just use WCAG 2? The one example you can give them is keyboard accessibility So WCAG 2 requires that everything be accessible to the keyboard But it doesn't require that everything be accessible to the mouse or everything be accessible to the touch screen So even though we tried to be technology neutral we did fail and why is mobile different? So firstly there are native screen readers that are built into mobile devices that you often don't see in PCs and things like that are things like talk back on Android voiceover on iOS You have volume control of a hat, dick or vibrational keyboard You can get visual auditory or vibrational notifications. There's screen rotation We're used to seeing things in portrait as opposed to landscape mono audio voice control Increased text and display size reduction of motion zoom reader view and simplified view now Yes, there are a lot of these things are on desktop as well But people aren't aware of them and people often have to buy a product or go looking for a product Whereas in in a mobile device It's just kind of taken for granted and my stepmother who would never Identify herself as having a disability uses a bunch of what we call these mobile accessibility features just because she's getting old and so, you know, it's something that people use a lot more than we would see in PC So what about and Mac of course, sorry, I know your developers. I'm not a developer. Can you tell? Okay, so WCAG 2.1 was released in 2018 a whole 10 years after WCAG 2 was released and this was supposed to be the You know the kind of iteration of WCAG 2 while they're working on WCAG 3 Which is called WCAG silver if you want to sound clever and so WCAG 2.1 was supposed to address all these issues Because the accessibility industry we're really quite good at kind of making our voices heard So we've had two different 2.1 definitely builds on this and addresses more criteria Related to touch screens such as pointer gestures and sensors and small screen devices However, it still doesn't cover all the user needs related to mobile accessibility now prior to 2.1 being released in 2018 it was like the Wild Wild West when it came to mobile accessibility every single accessibility company had their own mobile accessibility guidelines and One of the things that we found when we collated all these guidelines is every single one Required touch screen touch target size. So when you touch something It has to have it has to be a certain size because otherwise you can't touch it When it came to WCAG 2.1 They did have a touch target size requirement, but they'd relegated it to level AAA Which is not required by any government or policy Organization and as I like to say AAA is where success criteria go to die So, you know, it was basically useless. So 2.1 didn't address all the needs so a Group of accessibility specialists got together and developed a mobile testing methodology are all the major organized accessibility testing companies in the US and the UK were members of this committee that wrote this methodology and basically what happened is there's a testing Conference that occurs before covid occurred in DC around about this time every year and in 2017 we had this town hall where we got everyone together and at the end of the conference and said, you know, what's the issue that's most affecting us as accessibility specialists and it was mobile accessibility So we convened a committee and we basically collated all the mobile accessibility guidelines from all the accessibility companies around the world and Then we thought because it was 2017 we thought all WCAG 2.1 is going to address all this So we only have to do it once and then 2.1 came out and we went oh damn it So we reconvened the committee and we actually went through and we wrote them Fully and properly and I was the co-chair. We actually split into two committees One was the native app committee and one was the mobile site committee And so we basically developed these mobile accessibility testing guidelines, which are now the de facto Mobile testing guidelines now if you go, oh my god, why should we listen to you? The thing is accessibility specialists are very vocal and they're very big on just basically Doing their own thing if policy organizations like the W3C don't do the right thing In fact, WCAG 1 which was released in 1999 was developed by a series of accessibility experts That just got together in 1995 and wrote the guidelines. They were the de facto guidelines 1999 W3C adopted them and now they're they know I would have one we did we saw it with XML we saw it with HTML5 Over and over again, the policy organizations don't do what we see needs to be done And so we go off and do it and then W3C goes. Thank you very much. So That is how it sort of came about now. I'm going to talk a little bit about methodology obviously, but I just want to make sure you know that this methodology is everything that you need to do on top of WCAG 2 So you need to when you're creating native apps or mobile sites, you know Our methodology doesn't say you need to have text alternatives for images because that's in WCAG 2 So you need to do WCAG 2 and this methodology However, the things that were included in 2.1 We did include in the methodology, but it's very clear when we reference that because there's a whole bunch of times where We as a committee Decided that we did not agree with the W3C So let's talk about testing methods Testing methods for mobile sites. There's four main testing methods testing on a device Testing on a device with an assistive technology testing on a responsive window and testing on desktop When it comes to native apps, there are two main testing methods Which is basically testing on devices and testing on devices with assistive technologies because you really can't get To the code the way that you can with websites. And when I say websites, I mean applications anything, you know in a browser One of the things if the only thing that you take away from this presentation is you must test with real devices Simulators Do not work. Do not work. Did I mention did not work? Do not work. Okay, so this is back in before COVID and when I used to fly to The states every couple of months, which I'm doing tomorrow. Can you tell I'm looking forward to it? And the thing is is that I there was no internet on planes back then Can you imagine 15 hours without internet? I mean, it's really really hard. So basically we would We would fly would land at lax and we sit on the tarmac for an hour or two because there wasn't a gate open And the brilliant thing is when you're on the tarmac of lax, you can access the lax wi-fi Except when you access it with a mobile phone, which of course the only thing you can use at that point You get this little error. Well, it's not an error. It's a it's text. It says Sorry, I'm getting old This page will redirect so content doesn't really make sense to have here And all of a sudden I don't want to give you my email address I don't want to give you my credit card details And the emails can wait another couple of hours So this is why you have to test with real devices because how did this happen? Someone was testing it on a desktop computer somewhere They never went and tested it on the location and saw what happened So and I don't know how I managed to break things But it's a joy of being a tester But I always find the things like that the number of times I've heard clients saying Yeah, that's not that there's that's not an error. There's no way that that's our website. It's like I took a screenshot It's your website so Okay, so the methodologies have five steps The mobile site methodology is uh, they're very similar the only steps that are different Are step two now the the things that you need to do under the steps are different But the five steps are basically very similar step one identify devices step two identify site type and variations for the mobile site uh step three test critical issues step four test mobile specific issues And step five test mobile assistive technology and feature support So when you're testing a native app, the difference is step two where you need to define the application functionality So when it comes to identifying devices We basically came to the conclusion that you really only needed to test on an iphone an ipad and an android phone When it comes to a website on the ios devices You only need to test on safari and on android phone test on chrome and so if you are If you're western world facing the majority of mobile devices that are used are ios devices If it's more eastern world facing then it's android phones But in general people with disabilities prefer ios devices Because they're more accessible however in some cases they go for android phones because they're cheaper So it's a little bit complicated. You should look at your statistics basically Other devices you should consider are things like an android tablet And chrome as well and things like alternative devices such as a kindle device Now not for your just general website But if you've got something that you know people are going to use on a kindle Then that's when you need to look at it In terms of versions you only really need to test on the latest version of ios and ipad os And test on the latest two versions of android, but really you can get away with the latest version But be aware that if you have a site directly aimed at people with a particular kind of disability Consider including assistive devices and or assistive technologies used by potential users So if you have a website for people with acquired brain injury for example Then they're going to be using things like drag and naturally speaking and that's when you need to be testing with that However, the kind of thing that we have learned over the last few years because we release this methodology in january 2020 Just in time for covid The thing that we learned is that about 70 of the areas that you find on a mobile site Basically are the same on ios and android and then you have about 30 differentiation Native apps is a different kettle of fish depending how they're coded So when it comes to the mobile site Or application It's really important to identify your site type and variations of the page So you're all developers. You know what I mean by this But you know, you need to decide whether the site is a desktop an m dot site or a responsive site So desktop websites, they have one display whether they're viewed on desktop or mobile m dot they have a particular display for mobile and a different display for For pc's or max now this actually means that there's two websites So you need to test both websites as separate websites And then there's responsive websites, which is basically most of the web And so the screen changes as you You know different elements show up depending on the size of the screen Now if you're dealing with a client Don't assume that they know what their sites are because I ran mobile This mobile technology training for stanford and we found an m dot site that they didn't know that they had and they were the it team So, you know, you never know And the thing to be Really really sorry the thing to really look at is page variations. So basically You need to if your page varies say at a large size you've got your Navigation across the top and then on a mobile device it changes to a hamburger hamburger menu You need to test your navigation across the top and the hamburger menu They're two separate pieces of code But the one thing you need to remember Is that there will be people who look at your mobile version of your website on desktop Because they are increasing text size due to low vision and there are some cases where if you increase text size enough You'll find that a whole bunch of different features disappear like an image gallery or your login details or whatever And that's really problematic. So the other thing to remember is that All your page variations All the features of your website need to be available on all those page variations. They can be hidden They can be on a different page, but they need to be there and It's so as I said essential that functionality is not removed due to a variation in the page Uh, so basically what what do I mean by that? Uh, so this is youtube that fix this but 100% um text size on pc You can see the upload and notifications are visible And then at 200 when you increase the text size on pc they disappear Now why do they disappear because they think you're looking at it on a mobile device? And if you want to upload a video, you'll use the youtube mobile app mobile app Whereas you might be someone with low vision who's just increased the text size And then define application functionality for the native apps So basically you need to really think about the purpose of the native app and define which functionality is critical To use and it must be tested for efficacy operability and workflow So what do we mean by this if you look at the west pack mobile site? There's a whole lot of information on that website. You know, who do you go for stock broker tips? How do you apply for a home loan? Where do you go for a complaint? You know, where can you apply for a job? The west pack mobile app is very specific It's about managing your bank accounts. So native apps are very specific much more sort of than mobile sites So that's what you need to be aware of So ask the question How would the experience be impacted if the functionality failed? The content could not be reached or the experience caused a barrier to the user And then prioritize so all functionality should be accessible But it's important to define and include the critical functionality for each individual app and prioritize that And then you need to test common elements because there's a lot of common elements in native apps things like navigation landing screens emergency sections login flows settings accounts and profiles contact us Real-time updates privacy policy terms and conditions Interactional functionality help section widgets calendars, etc Geolocation or maps high traffic areas. I read them aloud in case there's someone with low vision who can't see the screen By the way, at the very bottom there is a link to these slides Which is pz dot tt slash mobile dash ds 22, but I'll tweet that out or something so you can get that later And you need to meet WCAG 2 and this mobile methodology And then step three is test critical issues So what we've found with mobile devices is that there are a lot more traps New features on mobile devices means there's a lot more traps So when a user is what is a trap when a user is trapped within a component And cannot escape without closing the browser or app And there are many more traps in mobile devices and the one that most people are aware of Keyboard traps you tab into a component like a video player and you can't tab out. It's incredibly inaccessible So we're identified five traps the exit trap the swipe scroll trap the text to speech trap the headset trap and layer trap So the exit trap is basically where you are Uh, you can't close something and therefore you can't get to the information underneath So the rule is ensure there is always an accessible actionable item E.g a close button that meets color contrast requirements and has an accessible name That closes any feature that overlays the current page such as a full page ad Applies to all users and it's in both methodologies. What do we mean by this? This is a full page ad on facebook. You'd think you could tap on the facebook URL at the top, but you can't the only way to actually you can't scroll up and down It's just stuck on your screen the only way to actually exit that is to exit the the app and start again This is another exit trap where you've got a pop-up that's advertising something Now the reason why this is an exit trap is because the close button Doesn't meet color contrast or touch target size requirements And the ability to tap outside that area is not enough to make it accessible Then we have the swipe scroll trap So ensure that you do not override standard mobile touch functions such as swiping or scrolling On the majority of the page applies to all touch users And it's both methodologies. This is my favorite example ever This is called the zoom of doom Basically if you have to if you want to scroll the page you have to hit these tiny little white areas outside the map Otherwise you scroll the map Now they actually you don't see this very often anymore But I like to keep it in my presentations because I presented it at my first mobile accessibility presentation in 2014 in new york And the day after coles was sued for being inaccessible So the next is the text to speech trap If the app has an ability to provide content via text to speech The screen reader user must be able to pause or stop the app speaking in a simple manner E.g. by performing a swipe on screen applies to screen reader users and it's the native app So basically if there's text to speech They need to be able to navigate through the page or stop it They can't navigate through the page if they are hearing, you know, an article being read So this is an example here where this is pocket You can press play it reads the article out to you But there's no easy way for the screen reader to stop that Playing and they just have to wait till the end of the article Then there's a headset trap So headset users must always be able to pause media Audio or video content by using the pause play control on the headset applies to screen reader users and headset users and it's both methodologies So this is an example here you go to a web page There's a little pop up at the bottom with a video that has audio There's a touch ability to kind of stop the audio But if you don't have the ability to touch And you are using a headset that headset pause pauses the screen reader not that audio And lastly we have a layer trap the user should not be trapped on a non-visible layer This applies to all users, but it's mostly encountered by screen reader users And sometimes keyboard users there are a lot of people that use keyboards on mobile devices And I don't mean the on-screen ones. I mean physical keyboards And this is both methodologies So this is an example here on the left you have a website on the right You have the menu open which overlays the page For keyboard and screen reader users the focus Remains on the underlying page. So they can't Close the menu. They can't access the menu. So that can be very difficult So the next step is test mobile specific issues We have different categories. I'm not going to go through all the errors Alternatives display actionable items navigational aids audio and video forms and the mobile and desktop relationship And then the fifth step is test mobile assistive technology and feature support So the rule is basically All actionable items and important content can be accessed and activated by the following assistive technology Or when the following feature is enabled And so on iOS What we decided we would include were voiceover keyboard keyboard and switch zoom reduced motion increased text size Invert colors grayscale and reader view on safari On android it's very similar talkback keyboard keyboard and switch Magnification remove animations color inversion grayscale color correction increased display size increased text size and simplified view on crime Now I know this is a lot of information. So guess what? It's all on our website. So if you go to resources Why are you not working? I oh Let me that's probably because you can't see it No, okay We're just going to pretend that it works. You go to accessibility os website There is a main menu item called resources and underneath that is mobile testing And we have a whole series of documents how to go about testing how to identify whether your site is You know an m dot or responsive how to capture errors And then we also have the test cases under each of those categories and we have a section about why it's important We have a section on how to test and we have a section on Good passes and fails. So there's heaps of stuff that's there So what's next? Uh, as I said, it was released early 2020. So we are reconvening the committee We want to include wicked 2.2 that was supposed to be released in april and then in june and then in september and now in december So hopefully one day Um additional assistive technologies and mobile features I have a great article on voice control and how it can really help you with your assistive technology testing Uh review existing test cases because there are some that we don't actually need Remove some of the assistive technologies and mobile features because sometimes they always pass or they always fail So you only need to test one And then create an online resource So I would love you to get involved Even if you don't feel like you know anything about accessibility if you're a developer mobile site native app If you even just have a little spare time, please contact us because we really really want People to help us The commitment is depending on whether you joined both committees or one Is a couple of hours once a fortnight? For the meetings and then you know, maybe a couple of hours research So the email address to contact us is mobile 22 at accessibility os.com Don't forget. There is a drupal south 2022 sprint tomorrow not tomorrow friday Go to drupalsouth.org for more information And please let me know if you have any quick grades Questions Also, I am flying to sydney immediately after this So if you want to just grab a card if I don't get to answer any questions, you're welcome to anyone got any questions Yeah, I've got a question. I can talk loudly Are there any accessibility concerns with scrolljacking like where the content of the page changes as you scroll Oh, yeah Yeah, so that has quite a few issues you can do it accessible Accessibly The state library of new south wales. I'm not sure if that's their current site But we worked with them about four or five years ago on that kind of feature It is difficult to do but it can be made accessible. We call them one page web applications and basically there's The major problems are around keyboard accessibility because if you're a keyboard user then if you're just Sniffing for the mouse, you know scroll then the keyboard user or the screen reader user just can't go anywhere So, yes, it can be done, but it's a little bit more difficult You mentioned about the like As a developer That's a So i'm actually presenting on video player accessibility in denver in a month Basically, I have done a review of video players every year or two for the last Six to eight years And there's only two that are accessible and remain accessible One of them is ours, which is called os player, but another one is called able player The others are getting better, but they all have kind of problems around that from a development perspective What I can tell you is that in you could you never accidentally make things accessible But most of the time we see things go wrong when people decide to You know create something new so I would say that In your example, it probably does work properly if you're just using an html 5 video player But I would I would have to reserve Rights to say that I may be wrong. Yes, but if you have an example feel free to send me It's on our website the last one we did was 2018 because did I mention covid? So we're going to do it over the next month We review about 37 and the problem a 37 different video players The problem is is that every year a different player Is more accessible other so excess so os player and able player are always in the high 90s percent percentile The others they don't really hit more than 60 percent And it's always different from year to year which player gets to that higher level So you can't even say oh overall YouTube is the most accessible player because it just changes every single year So yeah, but yes keep an eye on our website What was the name of the standard that you guys are making like you found you ever actually I didn't mention it Yes, it was very bad of me. Um, it's uh the mobile. Let's see if this will want to work now Oh, I don't know what's going on Oh, no, okay So it's see I'm clicking it. Nothing's happening. I hate technology sometimes You know, I I I did um web development Oh good. Okay. So under resources you got mobile testing and it's got no internet excellent So basically it's called the mobile accessibility testing methodology Um, that's what it is Let's try again Any other questions? While you're trying again, we should probably be talking to the microphone We should be and that's a terrible thing that I did to Uh, not do that. We should be talking to the microphone during the recording So this is the mobile testing site um or section and so It's got there's five documents for the mobile site testing methodology and five for the native app So you've got the section that's just the methodology itself think of like wicked too And then there's the about so devices assistive technologies site types variations of page capturing errors And what I've given you is an incredibly high level. Um, this is a 23 megabyte, you know Word documents, so there's a lot of information there And then you've got the critical test cases The test cases which are those alternatives display etc and the test cases for assistive technologies I don't recommend that you test an assistive technology Unless you need to use it in everyday life But in reality not all of us have access to people who need different assistive technologies So there is some basic information in that document about how you would test with say voiceover or a keyboard or things like that Any other questions? I'll repeat your question Go Yeah Yeah, so the question is what about well paraphrasing what about AR and VR So the person who runs the ICT accessibility testing symposium in 2020 went oh, you've been so successful with the mobile testing methodology How about you do an AR VR one and I'm like, I don't know nothing about those things So we are planned. I actually am the repository of people who Are interested in that so if you want to send me your details Then I once the committee gets formed, which I will not be a part of then they can you know contact you Would you like to run the committee? Any other questions Yes I was wondering if you think anything's from AAA Interesting that you say that so the question was do I think anything from AAA will be promoted to AA So that touch target size requirement has been promoted to AA in WCAG 2.1 Except the sizing is different because the w3c can't You know say that they were completely wrong. Um, there are a number of things around learning disability and low vision that They're such a long story So that have kind of Been modified slightly and moved to AA But one of the things that we did in this methodology when we said Okay, look, you know, we need to make them, you know mobile sites and things accessible We went well. There's a whole lot of really useful Guidance in AAA where no one looks so we actually included some things from AAA So it's very clear in the methodology. What's from AAA? But we did include those things so Hopefully The people who are doing WCAG silver are incorporating this information and it will show up there. Hopefully Yeah, so the question is are there any projects where AAA is important and yes, um We we actually have built a number of AAA websites For disability organizations, so disability rights, texas disability rights, washington Uh, you know, so those kind of websites where the main audience are people with disabilities That's where AAA is really important. Yeah I think I should probably like get off the stage Um, so but yes, please come up and grab a business card and I'll tweet out From the at accessibility os that that present url so you can access everything, but it's all on the website as well So thank you very much