Mobile Accessibility: Building and Testing Accessible Mobile Sites & Native Apps: Gian Wild

>> AMBER HINDS: Welcome to WordPress Accessibility Meetup, Mobile Accessibility: Building and Testing Accessible Mobile Sites and Native Apps. Today, our speaker is going to be Gian Wild. I will introduce her some more in a few minutes. I’m going to start with some announcements first. If this is the first time you’ve come, we do have a Facebook group. If you’re on Facebook, it’s a great way to connect in between meetups. You can join it if you go to facebook.com/groups/wordpress.accessibility. Share what you’re working on, get feedback, plug-in advice and recommendations, all sorts of good things.

We always get asked, “Is this being recorded?” The answer is yes, it is being recorded. It takes us about a week or two to get corrected captions and a full transcript, and then we will upload that to our website. You can find both upcoming events and past recordings in one place if you go to equalizedigital.com/meetup. If you want to get notified via email of upcoming events and when the recordings are available, we highly encourage you to join our email list, which you can do at equalizedigital.com/focus-state.

The other way that we are releasing these is as audio-only because we had a few people tell us they don’t really want to watch YouTube videos. They want to be able to listen to them in podcast format. You can find the audio-only if you go to our podcast, accessibilitycraft.com. They’re very clearly labeled as “meetup episodes” rather than the conversation regular podcast episodes. We are seeking additional sponsors for the meetup.

While this is part of the official WordPress meetup program, I was told by the community foundation that, unfortunately, they did not have funds to help us cover the cost of live captions or the post-event transcription, so they said, “Go out and find sponsors.” We do have a sponsor tonight, who I’ll thank in just a minute, but we are continually looking for new sponsors to help us cover the cost of running these meetups. If that is something that you or your company would be interested in doing, we would very much appreciate it. Please reach out and I would be happy to share with you what the benefits of sponsoring is.

You can also get information on the website on that same meetup page. There is a link over to find out about sponsorship as well. If you have any suggestions for the meetup or you need any additional accommodations to make it work for you or you’d be interested in speaking or there’s a topic that you want to learn about, you don’t necessarily want to speak about it, but you’re like, “Hey, can you go find a speaker for this?” we very much appreciate feedback or comments or questions. We’ll do our best to support you. The best way to get a hold of me and my co-organizer, Paula, is if you email meetup@equalizedigital.com.

Who am I? I’ve been talking at you for a while. I am Amber Hinds. I’m the CEO of a company called Equalize Digital. We’re a mission-driven organization and a corporate member of the International Association of Accessibility Professionals, which is abbreviated to IAAP. We are focused solely on WordPress accessibility. We have a WordPress plugin called Accessibility Checker that scans for accessibility problems and provides reports on the post-edit screen to make building accessible websites easier.

I’ve said our website about 10 times now, so I’m not going to say it again. You can find out more about us, what we do, and try our plugin. We have a very full-featured free version. If you go to our website, you can download it to install on your WordPress website. We are most active on Twitter as far as the socials go, though you can find us in many places. We’re just at Equalize Digital pretty much everywhere on the web.

Our sponsor this evening is GoDaddy. They are covering the cost of our live captions, which we very much appreciate. GoDaddy’s mission is to empower a worldwide community of entrepreneurs by giving them all the help and tools they need to grow online, including a simpler, safer WordPress experience. GoDaddy provides a managed WordPress experience that is as easy as it is effective.

The latest version of WordPress comes pre-installed with exclusive themes, plugins, and tools to get you up and running quickly with automated backups, updates, and malware removal so that all the pros who use GoDaddy can spend less time on monotonous maintenance and more time on building their business. I actually happen to host my personal website on GoDaddy-managed WordPress and I’ve been pretty happy with it. Of course, they do a lot to give back to the community, both through contributing to code and sponsoring events like this, so thank you. Shout-out to GoDaddy. If you want to learn more about GoDaddy, if you’re not familiar with them, their website is GoDaddy.com.

You can also find them on all of the socials. On Twitter, they’re just @GoDaddy. We always encourage people to give them a little tweet that says, “Thank you for sponsoring captions for WordPress Accessibility Meetup,” because it tells them that I did my job and I told you about them. It encourages them to want to continue sponsoring in the future and helping to make meetup accessible. If you are willing to do that on LinkedIn or Twitter or Mastodon, wherever you might be, give them a quick thanks for sponsoring. We would very much appreciate that.

There are two upcoming events that I’m going to talk about today. There’s a few more that we’re still figuring out, but the two most recent ones that I want to shout out is that on Thursday, May 2nd at 10:00 AM Central Time, which is going to be in the middle of the night for all of you in the APAC time zones, but Gen Herres will be speaking about giving quick accessibility audits. That would be a great one to tune into if you’re trying to figure out how to do them fast or for clients that have smaller budgets.

Then in the same time slot on Monday, May 20th at 7:00 PM US Central Time, we will be having Simon Miner talking about building empathy with stakeholders to drive accessibility. I also know that in May, we are going to do something for Global Accessibility Awareness Day. We are still finalizing the details of that because the speaker I was hoping to get, I haven’t been able to lock down, which is a little bummer. We are definitely going to have something, so stay tuned. Watch your email box if you’re on our email list or join it if you’re not and you’ll get notified when that happens.

I am very excited to introduce today’s speaker, Gian Wild. Gian, if you don’t mind turning on your camera, then I’ll be able to add a spotlight for you, but Zoom doesn’t let me do that. There we go. Gian is the CEO, founder, and president of AccessibilityOz, which was established in Australia in 2011 and the United States in 2015. Gian has worked in the accessibility industry since 1998. She worked on the first Level AAA accessible website in Australia, which is Disability Information Victoria, and developed one of the first automated accessibility testing tools, PurpleCop, in 2000.

She spent six years on the W3C Web Content Accessibility Guidelines Working Group, contributing to the development of WCAG 2, and is currently a member of the Automated WCAG Monitoring Community Group. I also had the opportunity to hear Gian give a similar talk for WordPress Accessibility Day Conference and really learned a lot. I’m very excited to have her here speaking with us today. Welcome, Gian.

>> GIAN WILD: Oh, thank you for having me. Today, I am talking about mobile accessibility. I apparently cannot share my screen. Oh yes. Now, I can. [laughs]

>> AMBER: I’m just stopping mine. As you’re getting sharing, I’ll give my final announcement, and then I will pop off here and let you take it away, and that is that we will be using the Q&A feature in Zoom. If anyone has questions, it’s easiest for us if you can please put them in the Q&A section rather than the chat because sometimes things get lost in the chat. Then I will come back on at the end and we will answer questions. I’ll let you take it away.

>> GIAN: Excellent. Thank you. Thank you, Adrienne. I am talking today about building and testing accessible mobile sites and native apps. Before we go any further, I’d like to acknowledge the Yuggera people as the traditional owners of the land that I’m currently on. I’m in the Gold Coast Hinterland. You can access this presentation from the AccessibilityOz website. If you go to the About section and then Conferences, it will be the conference linked there. The PowerPoint is linked, which is about 80 megabytes. There’s two PDFs, Part 1 and Part 2, about 6 megabytes each. If you have any trouble accessing them, please feel free to reach out to Amber, and I’ll make sure that I can send you a version that works for you.

I want to start off by just talking very briefly about accessibility, meeting our team. This was taken in 2018 BC, I like to say, “before COVID.” This is about two-thirds of our team. When I started AccessibilityOz in 2011, I wanted to support people with disabilities by providing them with employment opportunities while making the world a more accessible place. At any one time, about half to two-thirds of my staff have some kind of significant disability. Of course, you don’t know that to see, to look at us. That’s something to be really aware of when it comes to disability. It’s often what I say, “hidden in plain sight.” You don’t know whether the people you’re working with have a disability or not, so please don’t make any assumptions.

Over the years, I’ve had a whole bunch of different people with different disabilities work for me, including dyslexia, moderate vision impairment, severe vision impairments, epilepsy, migraines, physical impairments, fibromyalgia, multiple sclerosis, Crohn’s disease, post-traumatic stress disorder, autism, and long COVID. What’s also important to know is it’s not just about vision impairments. A lot of people, especially when they’re new to accessibility, think that accessibility is only about screen reader accessibility.

It definitely was a focus when accessibility started– well, when we started talking about web accessibility 20-odd years ago, but that’s not something that we should focus on now. In fact, the largest group of people with disabilities who use the web are people with cognitive disabilities. That’s because the largest group of people with disabilities are people with cognitive disabilities. I don’t mean just intellectual impairments. I mean things like epilepsy and migraines and dyslexia and other forms of reading disabilities.

A little bit about me just so you know that I do know what I’m talking about. I started, although this was kind of covered before, started in 1998. As Amber mentioned, I worked on the very first accessible website in Australia. I created Australia’s first automated accessibility testing tool, spent six years with the W3C working on WCAG 2. I worked on the Melbourne 2006 Commonwealth Games.

I’ve actually worked on every Commonwealth Games since then, including the aborted Victoria 2026 Commonwealth Games, and still waiting for an explanation about that. Then I spent five, six years managing usability and accessibility services at Monash University. I left there to found AccessibilityOz, released OZPlayer, an accessible video player in 2011, released OzART, our automated accessibility testing tool, in 2014, spoke at the United Nations on the importance of web accessibility, specifically regarding the Black Saturday bushfires in Victoria in 2015.

I was nominated for Australian of the Year in 2016 and I was inducted into the Centre of Accessibility’s Hall of Fame as Accessibility Person of the Year in 2019. One thing that is missing is from 2017, I have been chair of the mobile site and native app accessibility testing subcommittee. Now, that is a mouthful. I’d like to know a shortened version, [laughs] trying to come up with a good acronym. That’s what I’m talking about today.

Let’s start with a little background. There is this methodology. There are two methodologies that are very closely related. There’s the mobile site accessibility testing methodology and there’s native app accessibility testing methodology. There’s probably an overlap of about 85% that applies to both. Why did we develop this? What happened is that in 2017, I was at the ICT Accessibility Testing Symposium. This is a conference specifically aimed at accessibility testers. Thankfully, it is available virtually as well. If you are interested, please have a look out for that. It usually occurs in October each year. It’s based in DC. As I said, they usually have a virtual component.

At the end of this symposium, there was this discussion about– we call them a town hall, but basically a discussion about what the industry needs. In 2017, the overwhelming discussion was around mobile accessibility. WCAG 2 definitely applies to mobile, but there’s still a lot that WCAG 2 doesn’t cover. We were really thinking, “Oh okay, WCAG 2.1 is coming out at some stage. Hopefully, that will address everything, but we’re sick and tired of waiting. We’ve been waiting a while. What can we do until then?” All the big accessibility testing companies, they attend this conference.

We decided to put together a subcommittee to amalgamate everyone’s mobile accessibility testing guidelines. AccessibilityOz had mobile testing guidelines. TPG had mobile testing guidelines. Deque had mobile testing guidelines. Level Access, they’ll call it something else, had mobile accessibility testing guidelines. We just basically merged them all, got rid of the repeats, et cetera, and we released them in October 2018. It took us a year. We honestly thought that was a one-and-done situation. We thought WCAG 2.1 is going to be released. We don’t need to worry about it after that. WCAG 2.1 was released in June 2018.

Let’s talk about WCAG 2.1. Before we talk about WCAG 2.1, though, we need to talk about WCAG 2. WCAG, for those who are really new to accessibility, the Web Content Accessibility Guidelines, they are basically what you follow to make sure your website and digital content is accessible. WCAG 2 success criteria are definitely applicable to mobile. However, not all aspects of mobile accessibility are covered by WCAG 2.

For example, although WCAG 2 requires sites to be accessible to the keyboard user, it does not specify that it should also be available to the touchscreen user. That’s what we’re waiting for WCAG 2.1 to do. WCAG 2.1 definitely built on this and addressed more criteria relating to touchscreen, pointer gestures, sensors, and small-screen devices. However, it still does not cover all the user needs related to mobile accessibility. How did we come up with that conclusion? We released our guidelines just before the 2018 testing conference.

The town hall in the 2018 testing conference, the overwhelming discussion was around how WCAG 2.1 did not adequately address mobile accessibility. The really short version of that conversation is that every single mobile testing guideline that we looked at, all the ones that we’d amalgamated, agreed on a few things. One of the things that they all agreed on was touch-target size. Basically, when you’re trying to touch your screen that the actionable item is a sufficient size. There were differences in how big they should be, 15 pixels, 40 pixels, et cetera. We all agreed that there needed to be a minimum touch-target size requirement for links and fields and buttons and things like that.

WCAG 2.1 did include a touch-target size requirement. However, it was in AAA. AAA is where I say success criteria go to die. Most of the world requires AA compliance. There’s not one single country I know that requires AAA compliance. 99% of people ignore AAA requirements completely. There was that issue and a number of other issues as well that made us realize that WCAG 2.1 was not sufficient. We didn’t believe that if you followed WCAG 2.1 when building your website that it would be accessible to people with disabilities on a mobile device.

We didn’t think if you followed WCAG 2.1 building your native app that it would be accessible to people with disabilities. We reformed the committee. It’s a very long story. We started from scratch. We looked at everything, all the requirements, and all the guidelines. We looked at AAA requirements. We looked at articles. We talked to people with disabilities. At the end of 2019, we released the mobile site and native app accessibility testing methodology.

One thing to remember about the methodology is that it does not include those errors already included in WCAG 2. It doesn’t say your images need alt attributes and your headings need coded headings because that’s already in WCAG 2, but it does include those errors in WCAG 2.1. We wanted to include that just in case, say, a country had a policy of meeting WCAG 2, not 2.1.

There’s still a lot of things in 2.1 that you really need to meet if you want to make your sites accessible to mobile. It’s very clear in the methodology, by the way, when it’s a WCAG 2.1 requirement. In some cases, we disagreed with the kind of Benicia of the success criterion. We make that very clear and we explain why we disagree. One of the things we disagreed on, for example, is that on a mobile device, you should not have any content that requires horizontal scrolling.

It’s a portrait device. You don’t want anything that’s basically overlapping on the side of the device, so you’d have to scroll to get to it. There are exceptions to that. The exceptions WCAG 2.1 allows for are images and videos and tables. We don’t allow those exceptions because we think from an accessibility perspective that it is something that’s actually essential for people with disabilities.

Now, I’ve told you all about them. Where can you find them? You can download the guidelines from the AccessibilityOz website. You might say, “Well, hold on. I thought this was like a bipartisan development of guidelines. Why are they sitting on the AccessibilityOz website?” They’re sitting on the AccessibilityOz website for one reason only. I keep finding typos. [chuckles] Chris Law, who runs the ICT Accessibility Testing Symposium website, got sick of updating the documents. He said, “Just put them on your website. We’ll link to you.”

You can access them if you go to the AccessibilityOz website. You go to the Resources main button and then you go to Mobile Testing. There’s an introduction note on WCAG 2.1, mobile sites versus native apps, a note on hybrid native apps, and then there’s the methodology. The mobile site and the native app testing methodology. These are expandable. If you want a more detailed overview, you can get the overview here. If you don’t, you can just download the documents.

Each guideline has five documents. The first one is the methodology. Think of the methodology as being the equivalent of WCAG 2. Then there’s the About section, which is talking about how you choose devices, assistive technologies, site types and variations for the mobile site, how you capture errors, which is, of course, very important on native app testing. Then you have three sets of documents that have basically the methodology in a lot more detail.

You’ve got critical test cases and assistive technology and mobile feature test cases. Each one of these documents is very detailed. This is a native app accessibility testing document. You can see, there are a lot of pages. Let me just get to something that’s useful. We have this test. This is one of the iOS test cases on VoiceOver. It has the methodology requirement. It has about this requirement, some information about how to test, and then it has some example passes as well. There’s a lot of information in these documents. They are Word documents. One day, hopefully, they’ll be on the website, but not yet.

Let’s talk about mobile accessibility features. It’s really important to know that mobile is very different to desktop. One of the reasons that is not just because it’s a small screen size, look at it in portrait instead of landscape, but there are native screen readers. TalkBack on Android, VoiceOver on iOS, Voice Assistant on Samsung, et cetera. Now, there is a native screen reader to Mac devices, but not PCs. People who use PCs might use NVDA. They might use ZoomText. They might use JAWS. You don’t know what people are using. With the mobile devices, you do.

There’s also things like volume control, haptic keyboard, visual, auditory, vibrational notifications, screen rotations, mono audio, voice control, increase text and display size, reduction of motion, Zoom, and reader view and simplified view on websites. Now, all of these things or most of these things are available on PC and Mac devices, but the thing is, is that most people don’t know about them, whereas people are much more aware of them on mobile devices. I’m not quite sure why that is.

As an example, my stepmother, she’s getting old. She does a lot of reading, but she can’t read normal textbooks anymore. She reads all her text, all her books, all her articles, everything, all her newspapers on her iPhone because she can increase text significantly. Now, she would never think of doing that on her computer, but it was something that she figured out by herself. It’s something that we find is that these accessibility features are much more commonly used on mobile devices than on PCs. If something breaks, you’re going to annoy a whole lot more users.

Another thing I want to talk about when it comes to mobile issues is the whole concept of page variations. As part of WCAG 2, you need to zoom to 200%, which should already be included in your regular testing. What you tend to see is that if you zoom something on your PC to 200%, you end up getting the mobile view of the website. What tends to happen is if the mobile view of the website or the mobile page variation is different to the desktop variation, then those people who have low vision are restricted basically to the mobile version. If that mobile version has different content or less content, they can’t access all the things that they want to.

Therefore, it is essential that functionality is not removed due to a variation in the page. Now, if you’re like, “I didn’t get that,” this is an example. I just want to say, this is fixed years ago, but it’s just such a perfect example. This is YouTube at 100%. You can see in the top right-hand corner, you’ve got an Upload button where you can upload videos and your notifications. Previously, as I say, has been fixed.

At 200%, those upload and notifications disappear. Now, all of a sudden, you can’t upload videos. You can’t access your notifications. Now, why would this happen? Because YouTube assumes that if you’re looking at the page at this size, you’ll be doing so on a mobile device. They don’t want you to upload your videos through their website. They want you to upload your videos through the native app. That’s why they remove it. Of course, for someone who has low vision, who has increased the text size using their browser, all of a sudden, they can’t use YouTube.

Another thing to be aware of is this concept of accessibility supported, which is a conformance requirement, which states that implementation techniques that support assistive technologies used on mobile devices, such as TalkBack, VoiceOver, and Switch Control should be supported. Basically, the short version means that you really need to test with assistive technologies, especially on native apps, in a way that you haven’t needed to do testing on desktop websites.

Now, I am a big believer that the only people that should be testing with assistive technologies are the people who require those assistive technologies. We have someone who’s legally blind and uses a screen reader and he does 99% of our screen reader testing. Now, I will do screen reader testing if it’s something that he can’t access due to location or whatever, but his testing will always be superior to my testing because he uses it on a daily basis. He has an expertise level of knowledge that I will never reach. He also uses it differently to how I would use it because I have a concept of how websites tend to operate.

The other thing about WCAG 2 that maybe not many people know is the concept of WCAG 2 was technology-neutral, which was you should be able to meet all of the WCAG 2 requirements and not have to test with assistive technologies. We didn’t, when we wrote WCAG 2, want people to test with JAWS and test with NVDA, although I’m not sure NVDA was there back then, and VoiceOver and go, “Oh, it doesn’t work in JAWS, so we have to fix this thing,” which might then break it in VoiceOver. We wanted to include all the requirements in WCAG 2 and then get those assistive technology manufacturers to make their systems work with accessible sites.

Now, this doesn’t work so well with mobile sites and native apps because, with native apps, you can’t access the code. There’s also, once again, these assistive technologies that people use a whole lot more than they use on desktops. It is something that you want to do from maybe a usability standpoint. There’s quite a few assistive technologies that we recommend that you test with.

On Android, they include TalkBack, keyboard, keyboard and switch, magnification, remove animations, color inversion, grayscale, color correction, increase display size, increase font size, and with Chrome, increase text size, and simplified view. On iPhone and also iPad, we recommend VoiceOver, keyboard, keyboard and switch, Zoom, reduce motion, invert colors, grayscale, larger text, which is native apps only, and reader view, which is on Safari only, and reader view and increase text size, which is also on Safari only.

As I said, the iPad ones are all the same. If you look at the switch, I have no idea how to test with the switch. Well, I can tell you, I had no idea how to test with the switch either. We actually got someone who was reliant on a switch to look at our guidelines and recommend the how-to-test feature. There’s lots of information in those documents on how to do these things.

Testing methods. There are basically four testing methods for mobile sites and two for native apps. The four main testing methods in mobile testing is testing on devices, which is on mobile and tablet device, devices with assistive technology, which is basically a mobile or tablet device with an assistive technology or mobile feature, a responsive window, which is basically a responsively-sized window on desktop, and desktop.

There’s only two testing methods for native apps, that is devices and devices with assistive technologies. As a committee, we strongly, strongly, can I say “strongly,” recommend that you do not use simulators. Simulators are not a good representation of sites when they’re out in the real world or on an actual device. This is one example. This is from back when I was in 2014 and there was no Wi-Fi on airplanes. It’s a 15, 16-hour flight from Melbourne to LAX, which is a long time to be without internet.

Basically, what happens is you get to LAX and they often don’t have a gate because they don’t know the wing direction and stuff. They’re not 100% sure when the plane will land. There are times that we’re sat on the tarmac for an hour or two. The good thing is if you’re sitting on the tarmac, you can access the LAX Wi-Fi. However, this Wi-Fi, once you’re connected, says, “This page will redirect,” so content doesn’t really make sense to have here. All of a sudden, I don’t feel safe that I’ve given you my contact details, right?

Now, I have a really detailed seminar on this called, Mobile Accessibility: The Good, The Bad, The Ugly, of all the things that can go wrong when people don’t test properly. People use simulators. How did this happen? This happened because no one actually tested in the actual location. They tested. You may notice also, the text is really small. That happens quite a lot. That happens because people are testing on massive screens. They’re not testing on devices that are this big.

That’s why you must use simulators. When it comes to assistive technologies, there are some simulators that say they can simulate the assistive technology. They can’t. Don’t believe them. There are always things that will trip them up. If the one thing you take from me today is this. It is test with real devices. You only need an iPhone and you only need an Android phone. If you’ve got a testing team of two, you’ve probably got them already.

Okay, so let’s talk about the actual methodologies. The methodologies have the same five steps. Of course, what you do underneath them is slightly different, with the exception of Step 2. With mobile site, Step 1 is identify devices. Step 2 is identify site type and variations. Step 3 is test critical issues. Step 4 is test mobile-specific issues. Step 5 is test mobile assistive technology and feature support. The native app testing methodology overview is exactly the same, except Step 2 is define application functionality.

Let’s talk about Step 1. The first thing you need to do is to identify the devices that you should test on. Short version is Android phone, iPhone, but there are some things worth thinking about. In the United States, Australia, UK, other Western countries, iOS devices are most popular. However, in Asia and other Eastern countries, Android devices are most popular. It’s best to have a look at your Google Analytics or any other analytics system to see what is popular on your site. I’m not saying that means you can get away with not testing the other mobile device, but it might be you test first on Android and then you test on iPhone if Android is most popular.

The other thing to be aware of is due to the popularity of the Android system, there are tens of thousands of Android operating systems and browser combinations available. It’s not possible to test on all these systems. You need to really test on the latest version, Android phone running the latest version of Android. If it’s a website, test with Chrome. Now, Chrome is the best representation of what you’ll see across the majority of Android devices. Do not test with the internet browser that comes pre-packaged with Samsung phones as it is very dependent on the Samsung operating system. Unless the majority of your users or you have quite a lot of users that use the Samsung phone and the internet browser, then you might want to test with that as well.

The other thing to remember is even if the site is a desktop site and you’re like, “This is a desktop site. No one will ever use it on a mobile phone,” people will still use it on a mobile phone. Please be aware of that. Then talking about devices with assistive technologies, it’s important to remember that if you have an assistive technology that works on desktop and on mobile, say VoiceOver, they’re going to behave differently on desktop versus mobile because the code is different.

You need to test on mobile and desktop even if it’s the same assistive technology. You can have a look at the WebAIM screen reader survey to have a look at the latest screen reader usage, but my recommendation is basically VoiceOver for iOS and TalkBack for Android. Samsung does include an additional screen reader because Samsung likes to be different called Voice Assistant. However, TalkBack is still available as part of the accessibility suite. Most people who are expert screen reader users are probably more likely to use TalkBack.

However, once again, if you have a lot of Samsung users, then you might want to consider testing with Voice Assistant. Amazon Fire also has a different screen reader called VoiceView. If you’ve got content that’s going to be seen on Amazon Fire, you need to test with that. Basically, you can, most of the time, test on your iPhone with Safari if it’s a site, iPad with Safari, and Android phone with Chrome.

Now, unfortunately, iPad and iPhone actually have different operating systems, so you do actually have to test on both of them because your content will display differently. You also want to consider testing with an Android tablet with Chrome or alternative devices such as a Kindle device. In terms of operating systems, test on the latest version of iOS and iPadOS. The guidelines require or suggest, recommend the latest two versions of Android.

However, I have found that testing on the latest is sufficient. Also, when a site is aimed directly at people with a particular disability, consider using assistive devices and/or other assistive technologies used by potential users. For example, if it’s a site aimed at people with acquired brain injury, then consider doing some user testing with people who use Dragon, naturally speaking. If, just in case, you forgot, you need to meet WCAG 2 and this methodology.

For the mobile site requirements, Step 2 is identify site type and variations of the page. What do I mean by site type and variations? You need to determine if the site is a desktop site, an m-Dot site, or a responsive site. If the site is responsive, are there variations of the page? Desktop sites are sites that have only one display, whether viewed on a desktop or mobile or tablet device. m-Dot sites have a particular display for mobile and tablet sites.

The m-Dot site is a completely different code base from the website. That means that both the m-Dot site and the www site need to be tested on desktop. The m-Dot site and the www site need to be tested on mobile. It’s twice as much testing. Don’t use that m-Dot site. Then responsive sites that change depending on the screen size or other feature as determined by the developer.

Now, most of the websites are responsive websites. We also recommend that you only change the size or you only change the site dependent on the screen size, not by browser sniffing or anything like that. That way, people can access different versions fairly easily. That’s what is recommended. Now, for native apps, Step 2 is slightly different. Well, significantly different. It’s define application functionality. Through your understanding of the purpose of the native app, define which functionality is critical to its purpose and use and that must be tested for efficacy, operability, and workflow from a user experience perspective.

Now, what does this mean? Basically, if you have the Wells Fargo website and the Wells Fargo banking app, they are completely different things. The Wells Fargo website will have information on bank locations, information on the share price, information on how to apply for a job, information on how to make a complaint, information on home loan interest rates, et cetera, whereas the Wells Fargo banking app is very specific in its functionality, specifically about mobile banking. That’s what we find with native apps is it’s a much more specific set of content.

Ask the question, how would the experience be impacted if the functionality failed, the content could not be reached, and/or the experience caused a barrier to the user? Then prioritize. All functionality should be accessible within the native app. However, it is important to define and include the critical functionality for each individual app to be prioritized in your testing.

Then there will be common elements to test, navigation, landing screens, emergency sections, login flows, settings, account and profile, Contact Us, real-time updates like emergencies, privacy policy, terms and conditions, interactional functionality, help sections, widgets, calendars, et cetera, geolocational maps, and high-traffic areas. Just in case you forgot, you access this under the AccessibilityOz website under the Resources menu.

Step 3 is test critical issues. Critical issues are basically what we call traps. A trap is where a user is trapped within a component and cannot escape without closing the browser or the app. There are many more traps in mobile sites and native apps than on desktop. Although some of the ones that we’re finding on mobile sites, we’re also now finding on desktop.

What do I mean by a trap? On desktop, back in the late 2000s, Firefox had this problem that if you had a video player and you tabbed into the video player, you couldn’t tab out using the keyboard. You couldn’t escape from the video player using the keyboard. The only way for someone who is reliant on a keyboard to get out of that would be to actually close the browser and start again. Now, that is called a trap and it’s one of the reasons why we built OZPlayer.

We identified five different traps that occur on mobile and tablet devices. The exit trap, the swipe/scroll trap, the text-to-speech trap, the headset trap, and the layer trap. The exit trap, the requirement 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. This applies to all users and it’s in both methodologies.

This is an example of an exit trap. You’re on Facebook and this full-page ad pops up. Now, you can see at the top, there’s a little Back button. That doesn’t do anything. There’s a URL bar, can’t access it. The only way to get out of this is to hit this very small area and then the ad will disappear. You can see, there’s no Close button for the ad, et cetera. That is an exit trap.

This is something I’m sure we’ve seen many times before. It’s a dark UX pattern, but it’s also an exit trap. Basically, you’ve got a Close button. You got a pop-up. It says, “Hey, buy the full sale for The Chronicle.” The dialog box has the Close button, which is great. However, it doesn’t meet color contrast or touch-target size requirements because it’s too small and it’s gray text in the white background. Now, you might say, “Oh, you can just tap outside the dialog box.” Well, for some people, they can’t. They will get to this page and they can’t go any further. That is an exit trap.

Then we have a swipe/scroll trap. Ensure you do not override standard mobile touch functions, swiping, scrolling, et cetera, on the majority of the page. This applies to touch users and its both methodologies. This is what I call “the zoom of doom.” This is a map that’s on the page, takes up almost all the screen. If you scroll anywhere on that map, it scrolls the map. It doesn’t scroll the page up and down. You have to hit these very small areas of white to be able to scroll. That is very difficult. Now, we’re seeing a lot of maps saying, “Use two fingers to scroll,” and things like that. People are finding ways to address this.

Then there’s 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 a screen. This applies to screen reader users and it’s the native app methodology. However, we have started to find it on mobile sites. This is Pocket. I think they’ve fixed this actually.

Basically, Pocket saves all these articles that you want to read one day. My Pocket has thousands of articles that I’ll probably never look at. It has an ability to play the article. If you hit play, there’s no easy way to stop the text-to-speech. In order for a screen reader user to stop the text-to-speech, they have to navigate through the page to find a Pause button. Now, that is impossible for them to do because they are listening to the articles speaking. They can’t hear their screen reader audio. That is a text-to-speech trap.

Then we have a headset trap. Headset users must always be able to pause media, audio or video content by using the pause/play control on the headset. This applies to screen reader users and headset users and its both methodologies. This is an example here where you’ve got a little pop-up video from the bottom of a website. If you want to pause it, you can tap on the little Mute button here. Of course, if it’s playing on your headset and perhaps you’re using a screen reader as well, if you press the Pause button on your headset, it pauses the screen reader. It does not pause the audio or the video.

Then there’s a layer trap. The user should not be trapped on a non-visible layer. This is all users, but it’s mostly encountered by screen reader users and sometimes keyboard users, its both methodologies. This is an example here. You’ve got a menu that pops out when you select the Menu button. Even though the menu appears, the keyboard and the screen reader is stuck on the underlying page. That means that the screen reader user won’t get access to any of the menu content. It means the keyboard user can’t see what they’re doing and they can’t access any of the menu content either.

Step 4 is test mobile-specific errors. There are a bunch of categories in Step 4. Alternatives, display, actionable items, navigational aids, audio and video, forms, and mobile and desktop interaction, which is only applicable to mobile sites. In alternatives, we have nine requirements. 2.1, motion, interaction, and gesture. 2.2, touch gestures. 2.3, geolocation. 2.4, change of state. 2.5, audio cues. 2.6, status messages. 2.7, abbreviations. 2.8, summary of content. 2.9, ambiguous text. Let’s see a full example from the document.

Touch gestures, the requirement is any touch gesture must have an alternative, accessible, actionable item. This is very similar to the success criterion in WCAG 2.1 called “2.5.1: pointer gestures.” What’s a touch gesture? Touch gesture is swiping up and down or left and right, dragging up and down or left and right, double-tapping, tap and hold, tap and swipe, two-pinch zoom, and press and long hold.

What are alternative, accessible gestures? They are a link, a button, a dropdown, or a separate page with the same functionality. Then every requirement has an About This Requirement section, which explains why we think it’s important. 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, an up-or-down swipe, or some other gesture. Please note that this requirement is similar to the exit-trap requirement. A failure of the exit-trap requirement is that a user cannot escape from content or a page. A failure of the touch-gestures requirement is that the user cannot choose content or a page, i.e., they are not trapped.

Then there’s a How to Test section. Identify any site controls. If they require any of the following gestures, is there an accessible actionable item provided as an alternative? Then it lists the gestures. Swiping up and down or left and right or dragging up and down or left and right, double-tapping or two-pinch zoom, tap and hold or tap and swipe, and press and long hold.

This is an example of a pass. You’ve got two rows of content under the Top Stories heading. You can actually see that there is more content visible on swipe as part of the content is cut off. This is a very common way of a visual indicator of additional content. This is another actual requirement of the methodology. However, there is a link at the bottom called “See More.” The same content is shown when this link is activated as the additional content on swipe. It’s shown in a linear order. That way, people can access all the content even if they can’t swipe from right to left.

This is another pass example. When viewing the weather on Google, you can select and drag the slider to determine the weather at certain times during the day. However, you can also tap on the times to move the slider to that specific time. That’s another pass example. Then you have the display category, which has, 3.1, three flashes. 3.2, change on request. 3.3, target size. 3.4, inactive space. 3.5, fixed size containers. 3.6, justified text. 3.7, color contrast. 3.8, orientation. 3.9, animation.

Let’s talk about target size. The requirement in the methodology is that the size of touch targets is at least 44-by-44 CSS pixels, which is approximately 7 to 10 millimeters. This is similar to the WCAG 2.1 AAA success criterion 2.5.5 target size. We say in the methodology, please note that this differs from WCAG 2.1 as success criterion 2.5.5 is a Level AAA requirement. In this methodology, it is a mandatory requirement.

Now, why do we have this requirement? Most people use touch as the form of interaction on mobile and tablet devices. Touch is not as granular as mouse’s interaction and can depend on the size of a person’s fingers. People with certain physical disabilities may also find it difficult to activate very small touch-target sizes. There’s a couple of exclusions that we don’t allow. It has a fairly simple way to test, which is you identify all actionable touch targets. Then you turn on the screen reader and you can then swipe from each actionable touch target. The screen reader will actually outline the actionable item.

Therefore, you can measure it just with your ruler or something like that on your screen to see if it meets the size requirements. This is an example here. When visiting the Airbnb website, this is a long time ago, a pop-up occurs at the top asking if you’d like to install the Airbnb native app. The only way to close this pop-up is to activate very small close item in the top left-hand corner. However, the close item is very small. It doesn’t meet touch target requirements and it actually is much easier to aim for the Exit, Close button, but actually find that you activate the native app. This is not an exit trap as the pop-up doesn’t overload the page.

3.4, inactive space, which is very similar. Actionable items have sufficient inactive space between them. Inactive space of at least 10 pixels should be provided around active elements. Once again, as I said, most people use touch. People with certain physical disabilities may find it difficult to activate the correct item if multiple options are available without a minimum of inactive space. Once again, the How to Test is very similar. You turn on the screen reader, you determine where all the actionable items are, and you measure the space between them.

This is a failure. This is Asana, the Asana native app. In the top right-hand corner, you’ve got the Edit button and the Mark Complete. It’s very simple. It’s very easy and I’ve done it many times to accidentally mark something complete when you meant to edit it. Of course, it doesn’t meet the data retention requirements of WCAG 2. Once you’ve deleted something, it’s gone.

This is another example, Wikipedia. There’s no inactive space between the related articles. That can be problematic. This is a pass. Basically, you can see, there’s enough space between all the actionable items. Then we have the actionable items category. 4.1, content on hover, focus or input. 4.2, native UI. 4.3, descriptive text links. 4.4, non-keyboard options. 4.5, infinite scrolling. 4.6, color alone. 4.7, removal of touch.

4.6, color alone. Color alone should not be used to indicate actionable items if not underlined. A secondary method such as underline or bold should be used in addition to color. This technique’s aimed at visual users only. It relies heavily on the WCAG 2.1 success criterion, 1.4.1, use of color. This success criterion allows exceptions for actionable items that differ from text in color alone if the difference meets color contrast requirements of a 3:1 ratio. WCAG 2.1 does allow that you use color as long as the color contrast is 3:1. Now, the color contrast requirements for everything else is 4.5:1. We decided that wasn’t sufficient.

Mobile devices are, by nature, mobile and used in a variety of environments, including full sun and full darkness. This means that color differences that may be obvious to all users in an office environment or in your PC could be very unclear in other locations. In addition to this, actionable items on desktops provide feedback to the user when the user mouses over it. At a minimum, the cursor changes. Sometimes the address appears in the bottom left-hand corner. These are all additional indicators so that you know something is actionable that’s available on a desktop, not available on a mobile. That’s why we decided that we should include this requirement.

We did include an exclusion, which is basically the links that are not inline text, so your menu items and things like that. Navigation bar, button text. They still need to meet color contrast requirements, but they have enough visual information that color alone can be used. As I said, this is aimed at visual users. It’s not aimed at people who use screen readers. Basically, this is an example where links are just blue and the text is black. This would be a failure. This is a pass. You can see, you’ve got links. They’re underlined, so it’s fairly straightforward.

The next category is navigational aids. 5.1, visual indicators. 5.2, character key shortcuts. 5.3, descriptive headings. 5.4, inactivity timeout. 5.5, navigation features. I’ll just show you 5.1, visual indicators. Visual indicators such as arrows, Next and Previous buttons, have been used to indicate swipe or scroll areas or additional functionality. This is very similar to WCAG 2.1 success criterion 2.5.1, pointer gestures.

Basically, we talked before about when using a mobile device, there’s less feedback provided to the user as to the functionality as actionable devices and things like that. As a result, it’s really important to provide a visual indicator of the functionality. Basically, this is an example here where if you swipe– This is a BBC app. If you swipe from right to left, it actually moves to the next tab. You’re currently on Top Stories. You swipe from right to left and you get to My News. There’s no indicator that a swipe has that functionality. I found it by accident.

This is another fail here. You’ve got your days of the week. At the top, to access the Next Week, you swipe once again from right to left or left to right if you want to go to previous weeks. This is, once again, something that doesn’t have a visual indicator and this is something that does. You can see that the images are cut off on the right-hand side of the mobile. This is a very common way to indicate visually that if you swipe from right to left, there is additional content. Then we have audio and video. There are three requirements: 6.1: Transcript. 6.2: Captions. 6.3: Live audio and video. The transcript requirement is that all video and audio have an accessible transcript. How does this differ from WCAG 2, you may say? WCAG 2.1, at Level A, requires that you have audio descriptions or a transcript and captions. At AA, it requires you to have audio descriptions. There are some sites that can comply with WCAG 2.1 Level AA by providing captions and audio descriptions for their content and not a transcript. That would mean that the site was compliant with the WCAG 2 video and audio requirements.

Captions, of course, are essential to people who are deaf or hard of hearing. Audio descriptions are essential for people with visual impairments. However, there are groups of people who have difficulty with both, and those are people who are deafblind, so having a transcript at that point is essential. The transcript must include both the audio and the visual content of the video. It’s not sufficient to have a transcript of only speech.

This is a fail. This is Nancy Drew, The Curse of the Dark Storm. This is a CW app, and there’s a little description, tiny, tiny, tiny text, but there’s no transcript to the video or audio file.

This is another failure. This does have a transcript, but the transcript is only of the speech. It’s not any transcript of what you see on the screen.

This is an example. I dislocated my toes a few years back, and I had to do all these rehab exercises. This is a video that shows the exercise and is accompanied by a text transcript that accurately describes the entire video. The text is, “Sit in a chair with your feet flat on the floor, take a deep breath in and lift your toes up, hold the position, then relax.” You could actually complete that exercise without seeing the video.

The next category is Forms. There are seven requirements:

7.1: CAPTCHAs – basically, we say, “Don’t use CAPTCHAs.” 7.2: Context-sensitive help. 7.3: Error prevention. 7.4: Positioned field labels. 7.5: Visible field labels. 7.6: Accessible name, and 7.7: Form and keyboard interaction.

7.4 is position field labels. Field labels are positioned adjacent to their input field and appear closest to their respective input fields in relation to other field labels and other input fields. The mobile device has a small screen, so if field labels are positioned far away from their respective input fields, it is possible they won’t appear on the screen at the same time as the field they describe. In addition, where a field label is positioned close to another input field instead of its own input field, it can be unclear to some users which field the field label describes.

This is an example here of a site where you’ve got a Yes button- a radio button- and a No radio button. The radio button that is selected is actually the Yes radio button, but it’s closer to the No radio button. Now, this is made much worse because the No radio button, which is unselected, doesn’t meet color contrast requirements so you can’t really see it either. This is a pass where you’ve got your field labels and then you’ve got your field. That’s much more sufficient.

Lastly, we have mobile and desktop interaction. There are two requirements: 8.1: Consistency and 8.2: Linking between types of the sites. Links between different types of the site; desktop, m.dot, and/or responsive, have been provided where the site is not solely a responsive site. Basically, WCAG 2 clearly states that all functionality be available on all different variations of a responsive site. However, in some cases, an m.dot site is created specifically to provide limited functionality. For example, a map of the campus or something like that. In these cases, it’s adequate to provide limited functionality on the m.dot site, as long as the user can easily move to the desktop or responsive site to access all content and functionality.

Now, there’s also another reason, which is that sometimes your desktop site is easier to use, or your mobile site’s easier to use, or someone’s concerned that they’re missing content, which they shouldn’t be, but they might be concerned so they might want to check out the desktop site. Maybe the desktop site is easier for them to use. This is a fail. You can see here, this is the Metacritic website. You’ve got a “see full site” link at the bottom. You can link from the mobile site to the desktop site, but you can’t link back again.

This is also a fail– Sorry, this is a pass. I’ve got to fix that slide. Sorry about that. Basically, this is the IMD website, and it has a “view full site” link, and it takes you to the full site, which is the desktop site. You can also then go back to the IMDB mobile site. Unfortunately, this feature has been removed.

Then step five is test mobile assistive technology and feature support. All the requirements basically are, “All actual items and content can be accessed and activated by the following assistive technologies, all when the following feature is enabled.” Then we have all those assistive technologies again. On Android, that’s TalkBack, Keyboard, Keyboard and switch, Magnification, Remove animations, Color inversion, Grayscale, Color correction, Increase display size, Increase font size. Then, with Chrome, it’s Increase text size and Simplify view.

Then, with iPhone and iPad, it’s VoiceOver, Keyboard, Keyboard and switch, Zoom, Reduce Motion, Invert Colors, Grayscale, Larger text on native app only, and Reader view and Reader View and increase text size only on the sites. The iPads are the same.

I’m just going to show you an example of VoiceOver. Basically, the requirement is, “All actionable items and content can be accessed and activated by VoiceOver on iOS.” This is an example here where you’ve got your social media links, Facebook, Twitter, YouTube, and Pinterest; VoiceOver just reads it as link, link, link, link, because they do not have accessible names.

This is TalkBack Android. This is a little bit more complicated, but these are the kind of things you need to look for. Basically, this is a crossword, and if you activate the clue, you would expect that it would take you to that position on the crossword so you could fill it out, but if you activate the clue, all it does is swap your position from horizontal to vertical.

I know that’s a lot of information, but I promise you everything that I have said is in those Word documents. Let’s talk about what’s next. We have updates from WCAG 2.2. There are two additional Level A success criteria that are:

– 3.2.6: Consistent help – providing consistent help mechanisms.

– 3.3.9: Redundant Entry – information previously entered is auto-populated.

There are four additional AA success criteria:

– 2.4.12: Focus Not Obscured – the current keyboard focus is not hidden.

– 2.5.7: Dragging Movements – dragging has an accessible alternative.

– 2.5.8: Target Size (Minimum). Sounds familiar, doesn’t it? Targets have an adequate size.

– 3.3.7: Accessible Authentication – providing easy methods of authentication.

AAA:

– 2.4.12: Focus Not Obscured (Enhanced) – the entire keyboard focus is visible.

– 2.4.13: Focus Appearance – ensuring the keyboard focus indicator is visible to all.

– 3.3.8: Accessible Authentication (Enhanced) – providing easy methods of authentication.

Now, WCAG 2.2 was released in October 2023, and it hasn’t been endorsed by most governments yet, so this is fairly new.

There are also additional assistive technologies and mobile features that we should include, including Voice Control, increasing text size and font color from Reader View, and testing with a mouse.

We also need to review existing test cases. There are some cases that need review, such as Text-to-Speech traps that only were in the native app methodology and started to occur on mobile sites. The mobile and desktop consistency is great, but we need to have consistency between websites and the native apps as well. If you’ve got an Asana website, it needs to be consistent with the Asana native app.

We also need to remove some assistive technologies and mobile features. What we find is:

– Grayscale in iOS and Android.

– Colour correction in Android.

– Colour inversion in Android, and Invert Colors in iOS always fail together or pass together, so you only need to test one thing.

– Reduce Motion and Remove Animations; so Reduce Motion in iOS, Remove Animations in Android, also always fail together or pass together.

– Classic Invert doesn’t provide any additional testing information to Smart Invert.

Lastly, we need to create an online resource. Currently, these are Word documents, but it would be better to be a website that is searchable, easily updated, more likely to be used, and more accessible. I did start this late last year, but then I got sidetracked with my job. There are blog posts that have the first few things available, and I hope to get back on that at some point. Unfortunately paid work takes priority.

Now we are reforming the committee. I’ve been trying to reform the committee for a while. If you would like to join and feel that you don’t have enough information or you don’t know enough about accessibility, I learned so much about mobile accessibility through being on the committee. It was something we all had research to do to find things out. It’s a really good way to learn about accessibility. If you would like to be involved, please email us at mobile23@accessibilityoz.com.

Thank you for coming today. You can access the presentations at accessibilityoz.com/about/conferences. There’s a bunch of free things on our website that you can look up if you’re interested. Now I’m available for questions.

>> AMBER: Thank you. That was really wonderful, Gian. I appreciate all of your expertise and the great examples that you showed of passes and fails. It actually reminded me before I go into questions, I feel like you should add this to your list– Hold on, I’ll share my screen.

>> GIAN: Oh yes, definitely. I’m always looking for examples. I had the best time finding the examples. It was just so much fun.

>> AMBER: I’ll put a link to this in the chat also, but I’ll describe it just in case anyone can’t– This came up in our conversation on one of our podcast episodes. My husband Chris, was talking about how he would transfer things between our bank accounts, and apparently in the mobile app for Capital One, this is our bank, you have to slide across the button to confirm the transfer.

>> GIAN: Oh, yes. That’s terrible.

>> AMBER: I was like, “I wonder–” We were talking about it and I asked him if he’s ever tried to see if there’s an alternative or tested it to find out if there’s a different way. I don’t know. I found this in their help documentation where it’s explaining how to complete your transfer of your money between your two accounts. As you were talking, I was like, this sounds exactly like a failure that probably needs to be addressed.

>> GIAN: Yes, it definitely is. Please, please send it to me. I’ll add it to the document and I’ll remove your account numbers and things like that.

>> AMBER: Here’s the link directly to that image on Capital One’s website.

>> GIAN: Excellent. Thank you. There are so many things like that that you just– I do find it fun finding them all.

>> AMBER: I’ll go through the questions. If anyone has any and you want to add them to the Q&A, then I can pass them along. I also wrote down a few. I am curious– We had one about touch targets and then I have a follow-up about WCAG 2.2. This person had asked, “Would the touch target pass if the touchable area is 44 by 44 pixels, but the icon itself is smaller?”

>> GIAN: Oh, that’s a great question. Technically it would pass, but that’s actually something that we wanted to talk about in the next iteration of the guidelines because of this whole concept of inactive space, I showed you the example of Wikipedia where it met the touch target size, but there was no inactive space between it. I thought, “Well, the touch target sizes are sufficient enough, so we don’t really need inactive space,” but I’ve had so many people come back and say inactive space is so important.

Why do I talk about that? The reason why is if someone looks at something and goes, “That’s too small for me to touch,” even though they could, then it could be a problem. Maybe that’s something we need to define better in the guidelines. It comes back even to the slide to transfer your money. You said, “Maybe there is an accessible way.” Well, maybe there is an accessible way, but if no one can find it, then it doesn’t matter.

>> AMBER: The words literally on the buttons, say “slide” right? They might not even try to see, “Can I just tap it”?

>> GIAN: Tap it, yes. I did this presentation at CSUN years ago on the accessibility of Facebook. They didn’t have alt attribute images. I had someone come up to me afterwards and say, “I work at Facebook. We’ve just instituted alt attributes on images.” I said, “Oh, I looked everywhere and I couldn’t find anything.” He said, “Oh yes, it’s really hard to find.” I was like, “Well, if it’s really hard to find, then it might as well be inaccessible.”

>> AMBER: Not exist.

>> GIAN: Yes, exactly. That’s definitely something to take into account.

>> AMBER: I think the thought that I had, Let’s say you’re linking your social media icons, I don’t think it necessarily means that the icons themselves have to be 44 by 44, but if you had a 2-pixel border around the edge of the target, maybe the icon in there could be smaller, but now it looks like a button or something, right? It tells someone there is more space. I think there are ways to communicate that without necessarily meaning every icon you have is massive.

>> GIAN: Has to be massive, yes. Absolutely, a border would absolutely be sufficient.

>> AMBER: The follow-up question that I have for you is WCAG 2.2 introduced that AA guideline, which says that it passes if it’s 24 by 24 pixels.

>> GIAN: Yes, I know.

>> AMBER: I’m curious how you feel about that. Is it big enough?

>> GIAN: Uh, no. [chuckles] We talked a lot about what size to make the minimum target size. The most comprehensive mobile guidelines that were published before ours were the BBC Mobile Accessibility Guidelines, and that’s what we went with, which is the 44. We talked to a lot of people, we tested it a lot of times, 24 is not sufficient. But I kind of feel like they felt like– I don’t know, they [inaudible] [crosstalk]–

>> AMBER: They were trying to appease designers or something.

>> GIAN: Yes, something like that. When I was on the working group, there was definitely a, “Oh, but if we do that, then the designers will just throw accessibility out the window because they can’t do whatever they want to do.” Basically, I do find designers often are terrified of accessibility, but it’s not that hard to meet accessibility requirements. As long as you don’t have gray text on a white background. I don’t know why designers love gray text on a white background. I do think 24 is too small, but it’s something we’ll discuss when we reform the committee.

>> AMBER: Yes, cool. FJ asks, FJ says, “Curious about references to tap and pinch, as this seems to assume that end users have the ability to do so. Can you speak to alternative ways people with physical disabilities with fingers or hands use mobile devices?”

>> GIAN: Yes. There’s a feature in the iPhone, I’ve forgotten what it’s called, but it basically allows users to mimic those features using taps. Just like the tab button is mimicked by swiping from right to left using VoiceOver, there is a specific mobile feature that allows you to pinch zoom by using different easy, accessible features. Pinch, I don’t think is particularly accessible so that’s something that I would definitely want to have an alternative for. Absolutely, there are accessible versions of–

If someone who is quadriplegic, if they use voice dontrol, they could activate an item without tapping by saying, “Activate the search bar,” or something like that.

>> AMBER: Yes, or they might be able to say, “Swipe,” right, and that would work?

>> GIAN: Yes, exactly. Yes.

>> AMBER: I keep trying to find somebody who can come talk to us all about voice control and making sure things are accessible for that. I think a big thing with this to think about is if your accessible name matches the visible text on elements or things. That’s another thing that I wondered on that button that says Slide. I wonder if it actually has an aria label on it that’s like Complete Transfer or something, right?

>> GIAN: I actually wrote this article, I’ve put it in the chat, called iOS Voice Control saves the day. I will share my screen because the funniest thing is– It really is helpful to determine what the accessible names are, especially on native apps without having to use a screen reader or something. I found things like this, like the accessible name for live, L-I-V-E, is L-Y-V-E. The accessible name for the magnifier button for the search bar is a kiss. The accessible name for the back button is a rose. There are easy ways to turn it on and things like that. That’s definitely something to have a look at. Voice control is–

>> AMBER: Wait, hold on. Is that good?

>> GIAN: What do you mean?

>> AMBER: I’m totally thrown off. Those are mistakes or is that intentional?

>> GIAN: Those are mistakes. Yes. Those are mistakes.

>> AMBER: Okay. For a second I thought you were saying that was good and I was confused.

>> GIAN: No. No. No, no, no.

>> AMBER: Those are mistakes.

>> GIAN: These are ones that are good. Videos of the day, videos of the day, popular, my new, et cetera. This is just very, very strange. Voice control is really good. It came out about three months before we released the guidelines. We were like, “Should we include it?” We thought, “No, we’ve already got enough work.” It’s definitely something that needs to be included.

>> AMBER: Great. I actually had a second question, which is, can you recommend more alternative verbiage to phrases like “see more” or “read more”? Phrases that seem to assume people are sighted. FJ tends to prefer more content or simply more about article/topic, whatever that might be. Do you have any thoughts about that?

>> GIAN: People who are blind or vision impaired, they don’t tend to care if you use visual language like that; “see more” or “read more” or things like that. The one thing you need to be careful of is the use of the word “click” because click implies that you can only use a mouse, that it’s not accessible via the keyboard. “See more” is fine, no one’s going to get offended by that. However, you need to have links that are descriptive, and that’s actually a requirement in the mobile methodology that the link is descriptive outside of its content.

WCAG 2 AA allows that links can be descriptive in context. You could say, “Click here to download our report,” and the Click Here is the link. I think that’s terrible. Or, “See more to learn about our courses,” and the See More is a link. Our methodology would say that that link is not descriptive because it’s not descriptive by itself. I would suggest you’d say, “Read more about the iOS voice control. Read more about how you can save money with–” The whole thing being like– et cetera. That’s what I would recommend.

>> AMBER: One thing we’ve done if we’re writing instructions on how to do something, we’ll say, “Click,” or, “Activate” the Submit button or something like that, so it’s not always saying that it has to be clicked.

>> GIAN: We usually use the word Activate.

>> AMBER: I don’t know if I’ve really encountered– Obviously there are lots of different opinions. I think it’s nice to hear you have a similar experience to me that a lot of blind people don’t necessarily mind if you say like, “See more.” I know sometimes we worry if we’re being too ableist in our language.

>> GIAN: Well, talking about that–

>> AMBER: I have blind friends who tell me they’ll see me later.

>> GIAN: Yes, exactly.

>> AMBER: I’m like, hey, it’s okay.

>> GIAN: I also have an article on that called Communicating with People with Disabilities. It talks about that in a lot of detail, specifically around running user testing and things like that. I’ll put it in the chat as well.

>> AMBER: Thank you. We’d appreciate all the great resources.

>> GIAN: The steps are: Speak to the individual, respect their body and property, don’t make assumptions, use natural language, ask, and a note on invisible disabilities.

>> AMBER: Great. I’m going to try and go through the next few questions just quickly because we’re about at time and I want to be respectful of your time and everyone’s time. I’ll try not to chime in too much. We’ll see how we do.

We had a question that says, “How to keep up with the state after leaving a page and redirecting to itself while having the updated data.” I don’t know if you quite understand what that question is getting at.

>> GIAN: I don’t know what that question means. I’m sorry, [inaudible], sorry if I pronounced it incorrectly. If you can just rewrite the question, then I’ll answer that.

>> AMBER: Yes, maybe we’ll circle back if we can get a little bit of extra context on that one. Do you have opinions on WordPress themes that are best to use as a beginner to accessibility?

>> GIAN: Yes. If you search for Accessibility in WordPress themes, 80% of the ones you get will be accessible. That’s what I would recommend. You can also have a look at the AccessibilityOz website. We’ve got a section on our website about the websites we’ve built under Products, Accessible Websites, and they all have an accessible WordPress theme that we created. You’re welcome to use that if you want. I’ll put that in the chat.

>> AMBER: I’m trying to see if I can grab a link. It’s basically what you want to search for on WordPress.org if you’re looking for free themes is the Accessibility Ready. There’s a feature filter there, which is, I think, a good place to start.

>> GIAN: Excellent.

>> AMBER: Natalie asks, “What is the best way for those new to accessibility to learn how to design or build WordPress sites based best on WCAG?” Do you have some favorite learning resources that you like?

>> GIAN: Yes, I wrote them.

[laughter]

>> GIAN: The best thing I would recommend is we have these fact sheets on all these categories: images, PDF, video, interactive maps, HTML5, content, JavaScript tables, coding, keyboard, source order, forms, and mobile. They have really detailed content. You’ve got principles on why you’d want to make something accessible, impact on users. There’s what’s called a manager checklist, which is basically a testing checklist. The developer checklist is very detailed. Each one has a correct example. This particular requirement, which is visually dynamic information, such as a progress meter, should have a text equivalent. Here’s the code. You can actually see a live demo. You can grab all this because it’s all under creative [inaudible]. That’s where I would start. That’s why it was created.

There’s also under Resources, the CCC developer videos. I can’t remember how many, 16 videos, I think, on various different things. They’re all under five minutes on forms, HTML, and aria. That’s what I would recommend as well.

The WebAIM mailing list, I’ll put a link in the chat, is also very helpful. There’s a bunch of different free webinars that you can get from WordPress and all those different things. A lot of conferences release their videos for free after the conference. That’s something else to look out for too.

>> AMBER: Yes, I’ll put a link actually to WordPress Accessibility Day on our past event. You can go to each of the past events and all of the videos there. There’s a lot that’s WordPress-specific there, which I would definitely recommend. Of course, I mentioned at the beginning, but you can get all the meetup recordings off of our website as well. That’s a good place to start if you’re looking for WordPress stuff.

Erin is wondering, “Can you talk briefly about the orientation requirement in WCAG and your experience with that in the context of native mobile apps?”

>> GIAN: I’m not sure if I am answering or understanding correctly, but basically we have three requirements in the methodology. One is the ability to move between portrait and landscape and the other is that the system operates correctly in both portrait and landscape. Then the other is that it doesn’t swap unexpectedly from one orientation to another. That’s what I would– It doesn’t matter if you need to restart the native app for the orientation change to take effect. That’s another thing worth mentioning. Does that answer your question? Let me know if it doesn’t answer your question.

>> AMBER: Yes, I’m guessing that might answer his question. I think like on a website context, it’s just making sure it’s responsive, so in the mobile app, it’s a similar thing, right? That if you rotate your phone, it’s still functioning.

>> GIAN: Orientation– it works that way, it works that way, that kind of stuff. Yes, that’s what the orientation requirements are in the methodology.

>> AMBER: Okay, Tej asked, “What would be the best strategy or technique for displaying information or navigation for interactive maps on mobile with embedded content specifically within iframes?”

>> GIAN: I don’t know if I know how to answer that. I am not a developer. I’m not sure how to answer that, unfortunately. Tej, if you can send me a link to an example, I can definitely tell you what’s wrong with it and what’s right with it.

>> AMBER: I think one thing in general that I’ve learned from a lot of our users when we do user testing is that if we can avoid iframes, that is really helpful because iframes can cause some challenges for screen reader users. Maps always are though, if they’re embedded.

>> GIAN: Screen readers on desktop, they usually handle iframes if they’re coded properly. I can imagine iframes on mobile devices are just a really bad idea. I can imagine they don’t resize properly and all that kind of stuff. I don’t know if I’ve actually come across anything other than a YouTube iframe on a mobile device. Unfortunately, I can’t answer that question.

>> AMBER: You know what I do think of when I see this question too is when they’re talking about interactive maps, I’m thinking about like, perhaps if you went to the Airbnb website, and there’s a map where you can click on all of the different Airbnbs. I wonder if the solution here is, maybe if you do just have a website, it’s better to have a mobile app so that you have more control over how that map functions on mobile and then try to get people– like offer them, like, “Do you want to use the app instead?” when they go there. Give them that choice.

>> GIAN: I actually think that it’s easier to make content, even interactive maps accessible using HTML and using native app code. HTML has so many accessibility features built in. It’s easier to test, it’s easier to fix, it’s easier to access. I would say that you should be able to create an accessible interactive map on a website fairly easily. I know Google Maps has– I’m sorry, I just saw Eagle-Eagle saying something and it’s just really distracted me. I would have said that, Yes, you should be able to do that.

>> AMBER: 100%.

>> GIAN: I absolutely have to address Eagle-Eagle.

>> AMBER: Okay, yes, do you want to read what you got distracted by?

>> GIAN: Yes, Eagle-Eagle says, “disabilityrightsWA.org seems to have an accessibility overlay.” Oh my God. “We’re told this is not best practice.” We stopped working with them probably 6 to 12 months ago. It was the first that I have heard of them having an overlay and I am very disappointed in them. Absolutely do not use overlays. I’m going to check it now and see which one it is.

>> AMBER: I didn’t see it, but also I’m [inaudible]. Oh wait, there’s a heading for Accessibility Toolbar. Oh no, now it’s talking to me.

>> GIAN: I wonder if this is–

>> AMBER: It’s Recite Me.

>> GIAN: Oh no, it’s Recite Me. Look, Recite Me is not terrible. It’s not an overlay, as such.

>> AMBER: It’s more of a toolbar than a JavaScript fixer, right?

>> GIAN: Yes, it’s not an accessiBe. Recite Me, BrowseAloud, ReadSpeaker, they’re all meant to make it easier for people with disabilities to access accessibility features and things like that. It’s not an overlay per se. They have actually written a very comprehensive document about how these toolbars are not overlays and they should not be mistaken as overlays because overlays are bad. That accessibility toolbar is definitely– I don’t know how accessible it is. I haven’t tested it, but it’s not an overlay, thank God. The problem with finishing up with a client and then suddenly, all of a sudden, it’s like you weren’t even there.

>> AMBER: I have a final question and then I’ll let you go. When you were talking about testing and testing on all the devices, I think one of the things that came to mind for me is some of the challenge that we have, especially when we’re working with smaller clients, is testing budget. If we’re talking about, okay, we already know that we test on Mac and PC and we test with NVDA and JAWS and VoiceOver, and now we’re talking about needing to test all of the different mobile devices, iPad and iPhone and Android devices and all of that kind of stuff, I can envision that for a lot of organizations, there becomes a budgetary challenge to that. I’m curious, how do we weigh all of this for those clients? What thoughts do you have about making mobile accessibility testing as affordable as possible for smaller organizations?

>> GIAN: The thing is that you need to realize that when you’re building a website– or the client needs to realize, that you’re actually building two. Even if it’s a responsive website, you’re building a website that looks good on desktop and you’re building a website that looks good on mobile. That’s going to engender additional testing because you are basically creating a second version. You can’t really get away with not testing that content.

I will say from my several years, I can’t believe it’s 2024, several years of using this methodology, that about 85% of all the errors that you find occur on both devices. The assistive technologies are different, but something doesn’t display properly, is overlapping, or things like that, it’s most of the time going to occur on both devices. That’s where I think it’s valuable to look at your popularity and say, “Look, 80% of people using our site on mobile are doing so on iPhones. We have a restricted budget, let’s test it on iPhone.”

The other thing to think about is the accessibility features. We recommend a whole bunch of accessibility features. In reality, you can usually get away with testing with the screen reader and testing with the keyboard and testing with the invert colors and the kind of reader simplified view for the mobile sites. The other things are not so important. If your site is accessible via a keyboard, there’s a 95% probability it’ll be accessible to a switch user. That’s kind of how you can get around it.

We do testing and we now charge extra from our mobile accessibility testing because we found it added 20% to our workload. It just does. It does take time. It’s harder to get to the errors, it’s harder to get to the code. It can be difficult. There is that resource crunch, but you just have to explain to the client that you’re creating another version. That version isn’t going to be magically accessible or magically work. It needs to undergo testing just like everything else.

>> AMBER: Yes, that makes sense. I really appreciate everything that you have shared today. This has been wonderful. Tons of resources. I feel like I’m a little less overwhelmed now than I was when I first started looking at those Word docs. Thank you so much.

>> GIAN: They are rather overwhelming.

>> AMBER: Yes. We’ll have the recording up soon for everyone. Can you let everyone know again if there’s a good social media platform to find you on? I know obviously they can go to accessibilityoz.com, but is there a good place to find you as well?

>> GIAN: Yes. We’re AccessibilityOz on Twitter. I’m not brilliant at checking that. There’s also the AccessibilityOz company on LinkedIn. Probably the best way to reach us is email. I’ll put my email in. Which is gian@accessibilityoz.com.

The other thing I just want to say is I actually suffer from Long COVID so I may be slow to respond to your emails, but I will always respond. Sometimes people are like, “Oh my gosh, I sent that to you eight months ago.” I’m like, “I’m sorry.”

>> AMBER: I feel you on those.

>> GIAN: I do respond eventually.

>> AMBER: All right. Well, thank you so much. Thanks, everyone, who stuck around to the very end. We’ll be back in a couple of weeks with another meetup. Bye.

>> GIAN: See you later.

• View “Mobile Accessibility Building and Testing Accessible Mobile Sites” Presentation PDF – Part 1
• View “Mobile Accessibility Building and Testing Accessible Mobile Sites” Presentation PDF – Part 2