 Tena koutou everyone my name is Luke Percy I'm the head of web CMS at Catalyst While I myself might be new to the Drupal community Catalyst definitely isn't We've been giving back, you know giving back to the community is important to us and Catalyst developers are actively in helping Drupal's Issues queues as well as other external sites like Drupal answers Catalyst also contributes beyond code modules and Documentation such as hosting the Wellington Drupal meet-ups We're credited on over 30 issues in the past three months, but you can come check us out on Drupal.org if you want to see more I'm proud to introduce today Gian while she will be doing a talk on mobile accessibility testing mobile sites for accessibility something that we value at Catalyst as well and Let's without further ado get into it. Hi. Thanks everyone. Thanks for attending and thanks for our great session organizers And event there. I'd like to talk about mobile accessibility today now a lot of you probably aware that there are There's WCAG requirements around accessibility, so you know, why can't we just use them for mobile? And basically, I'll just give you a bit of a history. So the ICT accessibility testing symposium in October 2017 this is a conference that occurs once a year It's specifically aimed at accessibility testers and at the end of the conference we have what's called a town hall where we you know ask the Testers and the people in the industry. What is it that? I Really needs to be addressed in the accessibility industry that hasn't been, you know, really properly addressed and in the 2017 session the overwhelming majority of people talked about mobile accessibility testing and so the problem of course with Mobile is that WCAG wasn't written for mobile. I spent six years with the W3C Contributing to WCAG 2 and you know, it was released in 2008 Of course the first iPhone was released in 2007 But of course the majority of the work was completed in 2006 So we really just had no concept of how you know people would use mobile to access the internet So what we did first off in 2018 was the chair of the committee was we Amalgamated the various different mobile guidelines from around the world. So the BBC mobile accessibility guidelines The past yellow group had one as well We accessibility OZ had one and we also incorporated DQ's Accessibility guidelines as well. So we kind of incorporated all these into one set and we were really looking forward to Not having to do anything more again because when you WCAG 2.1 would be released in June 2018 So, you know, we thought this was a one-and-done kind of deal now Just I'll just sort of take a step back and explain why mobile is different to desktop Mobile has a lot of native screen readers Such as a talk back narrator voiceover It's very different to the desktop environment where people, you know, don't like the screen reader screen readers That are available like Jaws and go off and build something like NVDA. You really can't do that on mobile. You're stuck with the the mobile features that are Incorporated in the mobile device that you're using and not just screen readers. There's also volume control haptic, you know vibrational notifications Text-to-speech speech recognition zoom, etc and a number of system accessibility settings that you know people with disabilities Will use but a lot of people without disabilities or without Defining themselves as someone with a disability would use as well such as font size touch and hold delay screen rotation High contrast assistive touch and mono audio. And so you've got a lot of more people using these settings even if they aren't actually you know seeing themselves as You know having a disability and these settings can really, you know play havoc when it comes to mobile sites So let's go back to WCAG 2.1 But before we go to WCAG 2.1, let's talk about WCAG 2 So WCAG 2, yes Success criteria are applicable to mobile, you know, old attributes are required on images whether it's on a mobile site or a desktop site However, not all aspects of mobile accessibility are specifically covered by WCAG 2 So for example, although WCAG 2 requires sites to be accessible to the keyboard user It does not specify that it should also be accessible to the touchscreen user Which of course is a major requirement when it comes to mobile So 2.1 was released in June 2018 And it does address more criteria relating to touchscreen pointed gestures Sensors and small screen devices. However, it still doesn't really cover all the user needs related to mobile accessibility And if you ever have anyone ask you well, you know, what is it about 2.1 that doesn't? You know meet the real criteria that you know is needed in the real world The best example is touch target size So we've all had cases where we've gone to touch something and it's too small, right? And so you pinch zoom to make it larger or maybe you activate something that is close to it because everything's just too small Now that's a real problem for people with disabilities. So it's really important that You know that things have an adequate touch target size or there is an ability to say pinch zoom now That requirement is in WCAG 2.1 But it's relegated to level AAA and as I like to say level AAA is where success criteria and go to die So that is the problem is that yes, there is a really important requirement But people aren't necessarily going to even come across it let alone implement it in 2.1 So another thing with WCAG 2.1 requires Page variations so now this is actually required in 2 WCAG 2 as well But I just thought that I would Address it now because it's something that a lot of people get confused about so low vision users who use the zoom function Inherent in the browser often are restricted to a mobile view of the site on their desktop So as part of WCAG 2.1, you must be able to zoom to 200% and access all the functionality and everything as required And so that functionality is not removed just because you're increasing the zoom size And this is an example here, and I just want to say that it has been fixed, but previously in YouTube The uploaded notifications button on the desktop site were visible at 100% screen size But not at 200% screen size now Why would that be that's because they basically if you hit 200% screen size on a desktop You triggered the mobile view of the the site and so they assumed that you're looking at YouTube through the mobile site now Why would you get rid of your upload and notifications on the mobile version of YouTube? Because people would assume that you'd use the YouTube app to upload or you know access your account So therefore you wouldn't have it on the site However, of course people who are using the desktop version at 200% aren't ever going to be able to access those things So this is an example here Uploading notifications visible at 100% and at 200% they disappear So that there is a real problem and is why it's really important that whether you whether you have a mobile site or a desktop site that you provide all the same functionality on both versions of the site and Whether it's responsive or you have m.sites doesn't matter you need to have all the same functionality now You can hide the content if necessary, but you must have you know the same ability to do all the same things The other thing that was in WCAG 2 but is really important now with 2.1 is Accessibility supported so basically it means that if there are accessibility techniques inherent in a Device or a technology say PDF or HTML you must use those accessibility features And so that means that basically, you know if you're using a PDF you need to you know Tag that PDF But basically what it means for mobile is especially when it comes to native apps You really need to actually do testing with assistive technologies because there's really no other way to determine whether those Native apps are using the features inherent in the system Now so this methodology covers a lot of things But I just want to say it does not include things that are already in WCAG 2 So for example, it doesn't say hey your images need old attributes your headings need to be coded because that's in WCAG 2 But it does include the new errors that are listed in 2.1 and that's because you know some Some countries or some organizations might still be meeting WCAG 2 But want to make their stuff mobile accessible now. It's very clear when something's a 2.1 requirement We have made some minor changes. So we we disagree with some of the the things that 2.1 You know has come up with but we make it very clear in the methodology what that is So basically the most important thing to remember is that you really need to test with real devices So this is back when you know, I used to travel the world before COVID And I started doing a whole lot of international travel from 2014 and so, you know, it's a 14-15 hour flight from Melbourne to LA and You know, there'll be no Wi-Fi because it was back in the Dark Ages and we'd land on the tarmac And I would be able to access the LAX Wi-Fi however on this LAX Wi-Fi page it says This page will redirect so content doesn't really make sense to have here and all of a sudden I don't really feel safe giving you my email address or my credit card details or anything like that So how did this happen? This happened because someone was testing on a desktop They didn't test in the actual environment on an actual device so that's something that's really really important you must test with actual devices and If you have location Things you need to test in actual locations as well So back to the story of the methodology So 2018 the Committee reformed and said well actually as a committee. We're quite unhappy with how we can't 2.1 address mobile So they we decided to reform the committee and Split it into two groups one for native app Mobile testing guidelines and one for mobile site Testing guidelines that I was voted chair for both those groups. So we worked over the next year or so developing methodology a methodology one for native apps and one for mobile sites and they're both very very similar But today I'll be talking about mobile sites So basically the first thing we determined was the testing methods what testing methods should we really undertake when it comes to Mobile sites, so we decided that there were four main testing methods one was devices So testing on mobile and tablet devices Secondly was test devices with assistive technologies. The third was responsive windows So testing on a responsibly sized window on desktop and then also testing on desktop now You know notice there's no simulators there. There's no Kind of automated testing tools or anything like that we really decided as I mentioned before simulators are not good enough, but the Testing tools that are available really aren't robust enough to be able to rely on them at the moment So the methodology itself has five steps The first step is identified devices. The second step is identify site type and variations The third step is test critical issues the fourth step test Mobile specific issues and the fifth step test mobile assisted technology and feature support and the reason why I've highlighted step 2 Identify site type and variations. That's the only difference between the mobile site testing methodology and the native app Testing methodology is that that step is completely different when it comes to native apps There are different examples and things in terms of issues as well, but you know, that's where it really differs So let's move to step one Identified devices. So the recommended devices and browser combinations We identified was iPhone with Safari iPad with Safari and an Android phone with Chrome Now you can use a Samsung phone But if you do use it do not use it with the internet browser that comes pre-installed with Samsung phones Because that's very indicative of what people will see on Samsung phones Whereas if you use Chrome on Samsung, that'll be much more indicative of what everyone on the Android Devices will see And so it also when it comes to choosing your devices Definitely have a look at your statistics other things to consider Things like an Android tablet for example a Samsung Tab A or a Chromebook using Chrome again and alternative devices such as a Kindle device if you have Content that's specifically going to those alternative devices We're recommending testing on the latest version of iOS and the latest two versions of Android and of course where a site is Directly aimed at people with a particular kind of disability including assisted devices, you know used by those people So if you have a site that's specifically aimed at people with acquired brain injuries, for example You're going to specifically want to test with things like dragon naturally speaking You know and things like that because those are the kind of technologies those people will use and You know, I've said it before I'll say it again. You need to meet with add to and this methodology You know, you can't just get away with this methodology The second step is the site type and the variations of the page So the first thing you need to do is identify if the site is a desktop M dot or a responsive site And if there's a site is responsive are there variations of the page now? I know this is a Drupal conference So, you know, you probably all know what these terms are but I'm just going to go through it just in case So the desktop websites They only have one display whether viewed on desktop mobile or tablet M dot sites They have a particular display for mobile and tablet sites now if you have an M dot site You basically have two websites the M dot site needs to be tested against WCAG 2 on Desktop and WCAG 2 and the mobile testing methodology on mobile the And the other site also needs to be tested on both as well So you're actually doubling the amount of work that you need to do because if you think about it The M dot site is completely different site And don't think just because you've got an M dot site that people won't look at the desktop on your mobile device Or they won't look at the M dot site on your desktop Because they will they will always find a way and we also have a clause in this methodology that you can only Force users depending on to a certain You know responsive site or an M dot site versus on screen size not on device or anything like that because there will be people That absolutely want to look at the M dot site on desktop at 100% zoom or want to look at the desktop site on mobile And you don't want to stop them from doing that And then of course the one that we really should all be doing and is actually a requirement of WCAG 2.1 is Responsive websites and hopefully that's what you're all doing. So an example of a desktop site here This is the Australian National Botanic Gardens I just had to include this because this was the first website that ever went live in Australia It has 49,000 pages not a single web page that has ever gone up on this site has ever come down I do not recommend doing this when it comes to your websites But basically if you look at this on a desktop and you pull You make the browser Thinner you see the site doesn't change at all Whereas this is a desktop versus an M dot site. So this is a Sephora site You can see you've got your navigation along the top, you know, it's nice and brown Etc. Etc. And if you go to the M dot version, you'll see it looks completely different it's blue you've got your hamburger menu on the top left etc etc and In a mobile sales sized browser on desktop, you will see that they look completely different and Then of course, you've got the responsive site So this is the accessibility odd site on desktop. You've got your navigation along the top And then when you make it smaller the navigation changes the services change nothing really disappears It just all re-reformats as required So the next step is to test the critical issues So one of the things that we found really early on is that there are a whole lot more traps on mobile devices than they're on desktop devices So what is a trap a trap is where a user is trapped within a component and cannot escape without Conclosing the browser or the app think, you know 2012 Firefox video players A lot of people would keep, you know tab into the video player and couldn't tab out The only way to escape something like that if you're a keyboard user is to close the browser and start again So basically we identified things as traps where the only way to escape from the trap is to close the browser on your mobile You know or the native app So we found quite a few the first one was the exit trap ensure There is always an accessible actionable item e.g. A closed button that meets color contrast requirements or has an accessible name That closes any feature that overlays the current page such as a full page ad And so this is an example here Where the ad actually overlays the entire page and the only way to really close this ad is to close The app and start again This is an example for a website We've all seen these where it's got a pop-up that's trying to sell you something and the only way to close the pop-up is to hit that small Close button, which doesn't meet color contrast requirements or touch target size requirements And so, you know, basically you're stuck. You can't go into the site. You can't escape etc Swipe scroll traps ensure you do not override standard mobile touch functions swiping scrolling etc on the majority of the page so basically I don't know what I just did Computers so basically This is an example where You scroll down to the bottom of the page and you can't scroll up And the only way to get to the top of the page is to actually hit that little arrow at the bottom right and You know, everything else is disabled and of course that little arrow in the bottom right doesn't make color contrast requirements And you know, it isn't really understandable This is another example And I call this a zoom of doom. This is being fixed. This is one of the first errors I ever found but basically if you this the map takes up so much of the page that you have to hit these Tiny areas of white around the edge of the map to scroll the page. Otherwise you scroll the map Now a lot of people are finding ways around that now by Having like the two finger scroll and things like that, which is great, but we still see these occasionally the headset trap 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 This is an example here where you're on a website a little video pops up in the bottom as a touch user You can activate the mute Icon but as a headset user or a screen set screen reader user you you know activating the pause button will just pause the screen reader not that Video content and so basically they can't hear their screen reader. They can't use the rest of the page and Lastly 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 This is an example here where you open the Hamburger menu and the focus for the screen reader user or the keyboard user Stays on the page underneath so they can't access any of the menu information or close the menu So let's see an example from the document. So Here is touch gestures. So any touch gesture must have an alternative accessible actionable item And this is very similar to success criterion 2.5.1 in pointed gestures. Sorry pointed gestures in 2.1 So examples of touch gestures are things like swiping up and down or left or right Dragging up and down or left and right Double tapping tapping and holding tapping and swiping to pinch zoom and press and long hold And so the alternative accessible gesture must meet with add to or 2.1 Meet change of state meet touch targets meet inactive space meet native UI meet removal of touch And so basically the examples of alternative accessible gestures that are just inherently Accessible are things like a link a button a drop down, you know or a separate page with functionality So each requirement has a section that's called about this requirement which explains why we need to follow it So I'll read this to you now This requirement is particularly important for screen reader users For example, if you require your user to swipe right to complete a purchase when the screen reader is on the swipe Right gesture moves you to the next focusable item and doesn't complete the purchase You must be able to perform the same action by using a link and up and down swipe or some other gesture This note this requirement is similar to the exit trap requirement However, the failure of the exit trap requirement is the user can't escape from a content from content or a page Whereas the failure of touch gestures is that user can't choose content or a page or that as in they're not trapped And so we also have a section on how to test So we so basically you identify any site controls if they require any of the following gestures Is there an accessible action an actionable item provided as an alternative? And then we talk about the controls that are problematic. And so this is an example here Of something that is a pass of this requirement. So here you have We've got a series of top stories and the heading indicates So you can tell that there's more content by swiping by the fact that the content is cut off on the right-hand side But you can also see there's a link that says see more and if you activate that link It goes to a page that shows you all that content Another example here is the Google weather and so you can actually drag the weather to a particular time And I'll tell you what the weather is going to be but you can also just tap on the time as a link And that will tell you what the weather is So you can find these these resources at the on the accessibility odds website So I'll just show you now where you find them So basically this is the home page. I will and if you go to resources then Mobile testing you'll get the introduction information on Various different things and then the different methodologies. So this first document is the actual methodology, etc I think, you know, just the WCAG 2 requirements Or the equivalent of the WCAG 2 or 2.1 requirements And then you've got a second document about mobile site testing which talks about how you choose devices You know the assistive technologies how you choose site types and variations of a page as well as capturing errors And then there's basically these are the test case documents or the equivalent of success criterion So you've got the critical test cases Then the just the standard mobile test cases and then the test cases for assistive technologies and mobile features So I'll just show you the document now So this is the document For mobile site. This is the critical test cases document and so basically you have You know the information about the exit trap who it applies to about this requirement We talk specifically about timed ads and a section on how to test non-timed features how to test timed features And then we have some examples as well So we do that for each one of the methodology requirements. So there's heaps of information and you know, lots of things that you know, you can look at in terms of examples as what to do Now we are actually reforming the mobile accessibility committee because 2.2 is probably another six months off and where you know we've learnt from our mistakes when it comes to 2.1 and We have learnt that we can't necessarily rely on the W3C to address these requirements And I just want to say that this is not actually unusual for the accessibility Industry before the W3C Developed WCAG that there's actually a committee of interested accessibility Specialists who wrote WCAG and that basically got just past wholesale to W3C They made some minor changes and that was WCAG one So it's very common for the accessibility industry to sort of you know stand up in this way And I mean the BBC mobile accessibility testing Methodology was released in like 2012 2013. So, you know, as I said, it's very common for the accessibility industry to do this We've seen it with non-ICT things as well EN 301549 really is very much is the European accessibility requirements and They have taken on board WCAG and then gone that step further and applied WCAG to things like photocopiers and things like that. So as I said, it's very common for the accessibility industry to do this and We are very aware that hopefully at some point the W3C will take notice of us and Incorporate some of the requirements. I have staff We're a W3C member and I have staff on the WCAG working groups So and there are other people on the committee on the working group So it is something that we are, you know, trying to get the W3C involved in now This is also I just want to say the committee Was consisted of people from all the largest accessibility All the major accessibility companies around the world But we also had say mobile developers who didn't know much about accessibility But who could assist us in terms of, you know, why does mobile site do this? You know, why does it show this versus that etc. So we would love to have you involved If you don't know anything about native apps, that's fine. We're going to be continuing the separation between the two the two committees and So we basically will probably be a two-hour meeting every couple weeks with probably two to four hours of work outside the meetings And we're hoping to get something done in the next six months So we'd really love you to join us and honestly if you feel like you don't have experience The fact that you are listening to this is in, you know, enough experience Sometimes we just need to go out and, you know, do research and I learned a lot about mobile accessibility Just being on these committees. So please do reach out to us The email is enquiries at accessibilityos.com or you can email me directly gian at accessibilityos.com and I will hand over to Luke now and let's see if we've got any questions That was great. Thank you so much So I Haven't got any questions and chat yet, but I had a few prepared so In in the mobile space, what are you seeing is the most common, you know Simplest things that we could be addressing that you're seeing a trend in that we should be looking at first That's a great question. Um, I would say Design, you know, like people who design mobile sites and native apps are designing on, you know, massive desktop computers You know massive screens and they really don't know how it's going to translate into such a small screen So I think that it's really important that you get your color contrast, right? Because, you know, gray text on a white background is a bad idea I don't I feel like I've been saying this 15 years gray text on a gray background is a terrible idea Like and I'm really small, you know small things people can't read You know people can't click on etc So that would be one of them, but the other is use the native elements whether they're HTML Whether they're in the native app or things like that use the native elements because they always have accessibility in built If you have to create a new sparkling bat see, you know User interface component you are going to have to add in all that accessibility and the fact is is that even if it looks okay to you As soon as you, you know change text size or the color contrast or whatever It's going to go wonky. So use the native elements. That's probably the biggest thing that you can do nice and Also, it's not Important that an app looks the same on an iPhone as it does on Android because the native components are going to make Things look differently. It's much more important that you use the native components Than you try and make the app look same the same between the two devices because people are often You know this their iPhone users and their only iPhone users or their Android users or their only Android users So so then they don't swap between the two I myself have an iPhone and an Android phone for testing And the differences between the native UI elements are not major enough to really confuse anyone But people are really not swapping between devices like that Nice Something I'm seeing in the industry a bit is bilingual on page Yeah, have you seen a lot of that and in terms of getting accessibility issues from having multi-lingual? Content in page like on the same screen space I haven't seen anything that that's has caused problems, but that we did talk when I was Working on we can't to about left hand languages versus right hand languages and how that can really you know mess things up So that can that's something to keep an eye on Yeah, it's just yeah, just make things just that little bit more difficult What I will say is that the I haven't looked at recently but six months ago. I looked at the Google Language change feature so you can put it on your website and say hey change all the language to Spanish or or whatever And that feature itself is not accessible. So I would say It's less important that well, it's not less important But it's it's important that you have the ability to change the language or choose the language and make that ability accessible And then you need to sort of test both in terms of you know how things you know layout properly and what happens if someone you know You know increases the text size or something along those lines or uses a keyboard or something like that We do have a question here from Andrea think so do you need physical devices to test the accessibility or online tools sufficient for that You really need the physical devices now. You don't need to go overboard My team and myself we have one iPhone and we have one Android device each so you don't need to have like 15 you know, so I we We test on the latest version of iOS and we've found that it doesn't really matter if you're testing an iPhone 10 or an iPhone 11 or an iPhone 11 max or whatever there might be some functionality Issues but they're not accessibility issues. So, you know, if you you really only need to test on one iPhone iPad is different again because of course we've got iPad OS now So it's gonna be behaving differently. So you need an iPhone and an iPad and then the Android devices as I said as long as you're testing on the Chrome so far on the Chrome Browser you should be good to go. But the we have done a lot of Looking at Simulators and it just is not the same. They do not behave and especially when you start Throwing in accessibility features like increasing tech size Or the simplified view on Android Chrome to look at, you know, just the text of the Of the site those things just do not get replicated Properly on a simulator. So you really can't use a simulator now I don't I don't think that I'm not commenting on whether you use a simulator for functionality testing, you know Whether things actually work or not, but for accessibility testing, you really only need You know an iPhone an iPad and an Android device and an Android tablet if you want to go that far But yeah, so simulators you really when it comes to accessibility you cannot rely on simulators unfortunately The expert spoken all right Yeah, thanks for the explanation, that's great In your view which organizations have great mobile accessibility Good question Apple Yeah Google Also, and I will say so there's there's we looked at there's so many different accessibility features but one of them is called reduce motion and Basically what that does is it's it's supposed to on a site or a native app Try and like reduce any kind of movement and this is really important because Movement can be really difficult for people with ADHD in some cases that can trigger epileptic fits So you really do want to reduce as much motion as possible and we found it's so difficult to find a good example Well an example of someone who had accurately used reduce motion on a website and the only people that did was Google so and they had a set they had a It was Christmas a year or two ago and they had some kind of like Actually a sort of like a almost a VR experience where you you know went into like a Straight in London and you looked at the different Stores and then you went into the store websites and it had this beautiful kind of flowing effect But you know if you turned off reduce motion, it just worked really really well But that was the only past version that we and it was done by Google. It was the only Past example we could find So it's it is something that you know, I mean, I've been in this industry for like 20 several years and I I really I started off Testing just not accessibility but just testing testing and you know, we had to test on Windows 95 98 there's 2000 Windows Whatever that stupid one was Windows me or something and it was just like and it was I remember thinking Oh my god, and now it's we're kind of back there, right? where there's just so many different device combinations and You know like when we released the latest version of the guidelines we released them at the end of 2019 and iOS had just released dark mode and Text-to-speech and we're like we don't have time to investigate all these and you know Like we like we will do it in the next round Because it takes a lot of time to actually document these features and they're often not very well documented You know, there's so many different You know features that you can turn on that anyone can just stumble across on a mobile device That can just make your mobile site just crash and burn that you know, it's just it's like the Wild West out there It's kind of you know It's kind of like where we were 20 years ago with with websites and you know We'll improve like as we do and then something else will come along and we'll be like oh my gosh We all need to figure out how to make VR or AR accessible or something like that You know, but it still is just kind of crazy out there and some people do it Really well, but they're the ones that have a whole lot of money That can start playing with these things. So yeah, I haven't seen Anything I like I found a lot of the examples for the methodology the pass and the fail examples and I must say finding fail examples or a whole lot easier than Passing than finding pass examples and there wasn't a website that I could Reliably go to and say I'll find a pass example here So really yeah, it's just Apple and Google are kind of the ones that that know what they're doing Awesome. Well, thank you so much. It's been great to talk to you and listen to your talk And I'm sure we'll walk away as better developers. I hope so Feel free to reach out to me with any questions and you know Let us know it. Please join the committee But if you know, even if you don't please use the guidelines and please let us know what you think like Oh my god, that's so much work or this sounds really good But I didn't really understand X that we need feedback to figure out, you know, we you know When you can't see the forest for the trees, that's kind of where we're at at the moment So we need a lot of people with new eyes to look at these and sort of say yeah, this is good Or this is bad. So love your feedback Awesome. Thank you so much. Excellent. Thank you. See you later. See ya