Thread by @RohanIrvine

Last speaker for Day 2 Gian Wild @accessibilityoz — 'Mobile accessibility: testing native apps and mobile sites for accessibility'

#UXAustralia #uxaustralia2020

We're starting with accessibility fails.

Jamie Oliver has an autoplay video with no captions over the entire screen when you arrive on page.

Amazon had such low contrast between items that when they bumped up the contrast they improved sales by 30%.

ABC App in app settings — the resizing text size is not inherited by all of the text on the page

Asana failed with consistent navigation

So why did Gian develop a framework for testing mobile accessibility?

WCAG 2.1 didn't cover enough of the mobile accessibility features.

The system accessibility settings affect how people will be able to access an experience on mobile

You have to make sure that the mobile toggle is not text size because it breaks someone's experience.

All your content must be accessible on all experience.

WCAG2.1 says you must test with the assistive technology available on the devices

At the end of 2018 the committee Gian was on split into two committees, mobile sites & native app experience.

It focussed on things that were NOT in WCAG2 because it was assumed you would be following those basic requirements.

Test with real devices, in real locations, in real situations.

You may never experience what it's like to actually engaged in your experience and miss obvious issues.

There are four main testing method

Devices — Mobile site + Native App
Devices with assistive technologies — Mobile site + Native App
Responsive window — Mobile site
Desktop — Mobile site

Steps to identify an m.site

1. Ask client
2. Change url to start with m.
3. Look at the site on desktop and mobile and compare the different

Clients have sometimes told Gian they don't have an m.site and they one halfway through testing 😂

If a site is responsive, the is definitely not a desktop site and will likely not have an m. site

Variations in Page —

Each variation MUST be tested, and every variation of the page should have the same content available.

Why do you provide variations of page?

Highlighting particular content
Hiding particular content
Hiding functionality that doesn't work

You can't really have one variation of a page that has less content functionality than another.

The only real trigger for variation in page is the screen size.

If you have a hamburger menu it's likely a different piece of code so it must be tested.

Native Apps.

Define the application functionality.

They're different from websites because they have a narrow purpose. Be aware of the workflows for users.

Common elements you'll need to test

Mobile Testing Methodology

1. Identify Devices
2. Identify Site type and variations
3. Test Critical Issues
4. Test mobile specific issues
5. Test mobile assistive technology and feature issues

Native App Testing Methodology

1. Identify Devices
2. Define application functionality
3. Test Critical Issues
4. Test mobile specific issues
5. Test mobile assistive technology and feature issues

There are a whole lot of 'traps' in mobile sites and native apps.

It means that a user cannot 'escape' a part of the experience without closing the app.

Exit traps — Cannot get out of an element

Swipe / Scroll trap — can't move the map without zooming

Text-to-speech trap — once activated, screen reader users cannot stop the text-to-speech with their screenreader

Headset traps — can't pause audio through your headphones

Layer trap — when you're trapped on an invisible layer in the experience.

Gian is cover a lot of specific examples

— I'm unable to capture them all 😅 they're extremely helpful though so please check out the recording —

You can access the testing methodology and realted resources here: accessibilityoz.com/resources/mobi…

Gian would love you to use them, provide feedback about what worked and what didn't so they can develop the next iteration!

Thank you so much Gian! @accessibilityoz

#UXAustralia #uxaustralia2020

@threadreaderapp unroll please!