Forem: Mark Steadman

Accessibility Snapshot Testing in iOS

Mark Steadman — Fri, 20 Mar 2026 13:19:28 +0000

Snapshot testing is a popular type of regression testing that a lot of development teams are unaware has untapped potential when it comes to accessibility. The AccessibilitySnapshot library offers a way to bring accessibility into your automated regression suite. By treating the accessibility hierarchy as a testable artifact, developers can catch issues early and maintain a consistent, inclusive experience for all users.

What Is Snapshot Testing?

Snapshot testing is a regression‑testing technique that compares the current output of a component to a previously approved “snapshot.” In traditional iOS development, this often means capturing a visual rendering of a view and ensuring it hasn’t changed unexpectedly. It’s a powerful way to detect unintended UI shifts, layout regressions, or styling inconsistencies.

Accessibility snapshot testing applies the same philosophy, but focuses on semantics over pixels. The snapshot will include labels, traits, hints, element order, grouping, and the overall accessibility hierarchy. These items directly impact how assistive technology interacts with your mobile application, so treating them as part of your regression suite is a natural extension of of snapshot testing.

Running an Accessibility Snapshot

The Accessibility Snapshot Library from the folks at CashApp makes it straightforward to incorporate accessibility snapshots into your test suite. The library makes use of the already established 'SnapshotTesting' Framework, and allows you to add in accessibility assertions with ease.


    //Function to create hosting controller
    func createHost<Content: View>(_ view: Content) -> UIHostingController<Content> {
        let hostingController = UIHostingController(rootView: view)
        hostingController.view.frame = UIScreen.main.bounds
        return hostingController
    }

    //Snapshot test for home screen
    func testHomeScreenAccessibility() {
        let home = HomeView()

        assertSnapshot(matching: createHost(home), as: .accessibilityImage)
    }

In this test case we create a function to create a UIHostingController and then a test case to make a snapshot of the home screen of our application. When this test case runs, we will get an accessibility snapshot that looks like the following:

The output allows testers to be able to see the accessibility hierarchy of their application and check for semantic structure, grouping, or proper trait issues without ever using a screen reader!

Why Accessibility Snapshot Testing Matters

Reliable Regression Detection

Accessibility regressions are often subtle. A renamed label, a missing trait, or a restructured view hierarchy may not be visually obvious, yet they can dramatically affect how a screen is navigated with assistive technology. Snapshot testing catches these issues early—before they reach users.

Clear, Readable Output

One of the strengths of the AccessibilitySnapshot library is the clarity of its output. Instead of trying to use the screen reader light on the accessibility inspector or manually inspecting elements, developers and testers a structured representation of the accessibility tree. This makes debugging faster and helps teams build a shared understanding of accessible UI design.

Summary

Accessibility snapshot testing brings a powerful new dimension to automated testing in iOS. With tools like Accessibility Snapshot, teams can validate the structure and semantics of their UI with ease. The result is a more stable, predictable, and inclusive experience for users who rely on assistive technologies.

To see a full working example, please visit iOS-Automated-Accessibility-Library

Accessibility Regression Testing With XCUI

Mark Steadman — Thu, 26 Feb 2026 17:52:12 +0000

The question often asked in the mobile development community is, "I want to be able to add accessibility to my regression tests, but is there a way to do it?". There have been many open source projects created in the past that have allowed for it, but most of them either have stopped having support or are out of date.

Since Xcode 15, performAccessibilityAudit() is now a function that is readily available for use within XCUI tests! It runs the same automated checks as the "Accessibility Inspector" and allows for consistent regression of accessibility issues. So how do we make the most of it? Let's check it out!

Setting it up

The simple answer to setting it up is, if you have an XCTestCase using XCUIApplication() then you can call performAccessibilityAudit() on your content!


final class accessibilityAuditExample: XCTestCase {

    var app: XCUIApplication!

       override func setUpWithError() throws {
           continueAfterFailure = true
           app = XCUIApplication()
           app.launch()
       }

It can be triggered on any XCUIElement, which means you can scope your checks to the entire app, a specific screen, or a single component.

Performing the Audit

To have the audit be performed on the current application screen, simply call 'app.peformAccessibilityAudit()'.

Here is a simple example of setting up an application, and then performing an audit on the home screen:


//Performing Accessibility Audit on Login Screen
func testLoginScreenAccessibilityAudit() throws {
        XCUIApplication().tabBars.buttons["Home"].tap()
        try app.performAccessibilityAudit()
 }

Test Case Setup

With the ease of using the accessibility audit functionality, you can decide how you want to do the testing. There are multiple ways in which you can set it up:

Accessibility has its own test suite

Instead of doing regression tests as part of the usual suite of tests, you would make accessibility test suite that runs through the application and ONLY tests that content. (do not recommend, however there are reasons to do so)

Each XCTestCase has its own accessibility test

For each XCTestCase there is a test for accessibility (or multiple) that live with the rest of the tests. This is a great way to integrate accessibility as part of the normal regression testing process, while also calling out accessibility as its own test.

Accessibility test is added to each test case

Instead of making separate tests for accessibility, simply add it in as part of another test case. For example, if you were testing the functionality of a login screen (entering text, error messaging, etc.) and then during that you would run an audit for each stage!

Data and Results

When the test case has been completed, you can see the results in multiple different ways. In the test navigator, if you click on fail test case it will take you to where the issue is and showcase the issues found in line in the code with the test

The other way is to go to the report navigator, and under tests you will see the issues found with their descriptions.

In Summary

Bringing the Accessibility Inspector functionality into your XCUI test suite gives your team a first‑party, reliable, and maintainable way to catch accessibility regressions automatically.

By integrating audits directly into your existing XCTestCases, accessibility stops being an afterthought and becomes part of the natural development and QA process. It’s simple, built‑in, and it finally gives iOS teams a dependable path to automated accessibility regression testing.

To see a full working example, checkout the iOS Automated Accessibility Library

Accessibility Testing with Playwright Assertions

Mark Steadman — Thu, 19 Feb 2026 02:03:09 +0000

Playwright has become one of the most popular testing frameworks for web applications. During it's rise, teams using it have been looking for quick and effective ways to test for accessibility.

Libraries like playwright-axe or @axe-core/playwright are a great starting point, but they only scratch the surface, giving very generic scans of your HTML content to give the lower 25% of accessibility issues. To truly validate the accessibility of the experience your users rely on, you need deeper, more intentional checks. That’s where Playwright’s accessibility assertions come in.

Using Playwright Axe

Playwright-Axe is a popular way to add automated accessibility scanning to your test suite. It integrates the Axe engine directly into Playwright tests, allowing you to run accessibility scans as part of your end‑to‑end workflow.

How to Use It

In your test setup function, (beforeEach, beforeAll) add in injectAxe(page) to get axe added into the page, and then whenever you are ready to do a scan of the page in a test case simply call checkA11y(page). Here is a code sample:


  //Injecting axe into the page object before every test case
  test.beforeAll(async ({ browser }) => {
    const context = await browser.newContext();
    page = await context.newPage();
    await page.goto('https://www.normalil.gov/');
    await injectAxe(page)
  });

  test('Axe Playwright Simple Scan - No customization', async () => {
    await checkA11y(page)
  });

What It Catches

Axe is great at identifying very basic accessibility regression issues such as:

Missing or empty alt text
Color contrast failures
Incorrect or missing ARIA attributes
Structural issues like missing landmarks
Form fields without labels

These issues are the very bare minimum of issues you can catch, and can only generically check your content for issues. This is where Playwright Assertions can help take your tests beyond a simple accessibility scan.

Using Accessibility Assertions

Playwright includes a set of accessibility‑focused assertions that let you write specific regression tests that go beyond a generic scan of your page content. Let's take a look at the 3 assertions:

toHaveAccessibleDescription

This assertion checks that your element, has a proper associated description. For example, if you had an input field that had an aria-describedby tied to it with more instructions to help users understand the input, using this assertion can be used to ensure ARIA is being associated properly.


  test('Playwright assertion - toHaveAccessibleDescription()', async () => {
     await page.goto('https://accessibility.deque.com/contact-us-ga');

    const emailField = page.locator('input[name="firstname"]');

    await page.locator('input[type="submit"]').click();

    await expect(emailField).toHaveAccessibleDescription('Please complete this required field. (First Name). Press Tab to go to the input field to fix this error.');
  });

More Reading on Accessible Description: https://playwright.dev/docs/api/class-locatorassertions#locator-assertions-to-have-accessible-description

toHaveAccessibleErrorMessage

This assertion checks that an error message is associated with an input field when an error is present. One key thing to note, this ONLY works with aria-errormessage. If you associated your error messages via aria-describedby then you'd want to use the previous assertion.


  test('Playwright assertion - toHaveAccessibleErrorMessage()', async () => {
     await page.goto('https://accessibility.deque.com/contact-us-ga');

    const emailField = page.locator('input[name="firstname"]');

    await page.locator('input[type="submit"]').click();

    await expect(emailField).toHaveAccessibleErrorMessage('Please complete this required field.');
  });

More Reading on Accessible Error Message: https://playwright.dev/docs/api/class-locatorassertions#locator-assertions-to-have-accessible-error-message

toHaveAccessibleName

This assertion ensures that the object in question has the correct accessible name. This check can be very effective for complex tables with buttons, list of icon buttons, and ensuring that any action item has no misspelled words in the label!


  test('Playwright assertion - toHaveAccessibleName()', async () => {
    await page.goto('https://www.normalil.gov/');

    const rightSlideIcon = page.locator('.alwaysDisplayArrowNew.next');
    const leftSlideIcon = page.locator('.alwaysDisplayArrowNew.prev');

    await expect(leftSlideIcon).toHaveAccessibleName('Previous Slide'); 
    await expect(rightSlideIcon).toHaveAccessibleName('Next Slide');

  });

More Reading on Accessible Name: https://playwright.dev/docs/api/class-locatorassertions#locator-assertions-to-have-accessible-name

In Summary

Axe and other accessibility libraries are powerful, but it’s only the beginning. Automated scanners catch general accessibility issues but using Playwright’s accessibility assertions fill a larger gap in regression testing by:

Testing the computed accessibility tree
Ensuring accessible names, descriptions, and error messages are correct
Preventing regressions as your product evolves

If your goal is to build interfaces that are truly accessible, not just “passing a scan,” assertions are the next step!

If you'd like to see a working example checkout the Automated Accessibility Example Library which houses a playwright example that show cases all the items talked about in this article.

iOS Accessibility Inspector: Beyond Automation

Mark Steadman — Fri, 20 Jun 2025 12:13:01 +0000

Xcodes accessibility inspector has long been thought of as only an 'automated' issue tool. This thought has led to its full potential never being fully met by developers and testers. So if it's more than just automated issues, then what should users be doing with it to catch more accessibility bugs? Let's dive right in.

Simple Testing List

Keeping it simple, there are 3 main categories of tests you can do to ensure you are getting the most out of the accessibility inspector:

Action Name/Role
App Navigation (Screen reader light)
Dynamic Type (Font size increase)

Setup Before We Begin

To access the XCode accessibility inspector, you must have Xcode open and then go to Xcode > Developer tools > Accessibility Inspector.

Once open, it may default you to the "Audit" function of the application. You need to navigate to the "Inspection" tab and ensure your screen looks like the one shown below in the image. If it does, you are ready to test!

Action Name/Role

Automated checks can only tell if an action has a label or has a trait, but what it cannot do is tell you if the label or the trait actually describes the purpose of the action!

Action Test 1: Proper Label

Once the action item is selected (highlighted) in the inspector, ensure the label properly describes the action item. For example, if the button is a "Search" icon, the label should be "Search" NOT "IC Search, icon".

The label also MUST NOT include the trait in the label. Using the search example above, we would not want it to read as "Search, button". As it would actually read, "Search button, button".

Action Test 2: Proper Trait

Once the action item is selected (highlighted) in the inspector, ensure the trait for the action properly correlates to the expected action.

One prime example, buttons vs links. A button should keep you within the application while a link should take you to a WebView or out of the application.

Action Test 3: Over-riding Label

The final test, check that the label that is set does not override the visible text. Overriding visible text can make it confusing mainly for voice control users. Who can use "show text" to be able to tap a button.

For example, if the login button on your app visibly says login but the accessibilityLabel for it says "login to your application" it may not function with voice control.

App Navigation (Screen reader light)

Accessibility inspector comes with a screen reader built in (similar to that of Voice Over) that allows you to hear and navigate the application as a screen reader user would! The advantage of this, is not all iOS developers have access to physical phones to test with VoiceOver!

Navigation Test 1: Accessibility focus order

Pressing the "Play" button on the Navigation group, let the navigator go through one by one of each item in the application and highlight each item.

As long as the accessibility focus order goes from left to right in a concise and simple order that matches that of the visual order, then you are good! If it jumps and skips around the view while using it, then you have focus order issues.

Navigation Test 2: Proper grouping

Using the Navigation section, use the arrows right and left to navigate each item one by one in the view. While doing this, look for groups of content that could easily be put together.

The example image below shows a card component that can have the name, image, and description grouped as one, and then the "Add to Cart" button as the next accessibility focus stop. However, in this case they are all individual accessibility focus stops.

Dynamic Type (Font size increase)

The final test is for dynamic type! Which is a very simple test to ensure that your application properly is using dynamic type in your mobile application and the text resizes!

Different than the other tests, you will have to navigation in the top right to the "Settings" (the third button to the right). Once there, you will notice a number of different accessibility settings. Go to the bottom and select "Dynamic type".

Once you do that, simply move the slider up and ensure that the text does not do the following:

Overlap over other text
Addition of trailing ...
Overflow its container and get cutoff

In Summary

Accessibility inspector is much more than just automation. Using these simple tests in daily development and QA, can help ensure that your application goes beyond the basics of automation and does more to ensure its accessibility!

Debunking the Myths of the iOS Accessibility Inspector

Mark Steadman — Tue, 08 Apr 2025 11:53:55 +0000

One of the most commonly overlooked tools in iOS development is the XCode accessibility inspector. The inspector is a free tool that comes with XCode that you can use to help test your application for accessibility issues. Over the years however, the tool has gotten a bad reputation for being unreliable and only being an "automated" checker.

While some of the functional issues with tool are completely valid, the tool itself is so much more than just automated audits. Lets dive into some of the big myths about the iOS accessibility inspector and debunk them!

Myth 1: "Only Automation"

While it is true that the inspector has an audit function that runs automated tests, the myth that it ONLY does this is false. There are two big features that developers miss in the tool, the ability to manually inspect each element and screen reader navigation!

Manual Inspection

You can access each individual element on the screen by using the "Inspection" tab. Once you target your application you want to test using the target button, you can use the arrows under "navigation" to go through each item in the screen one by one.

For each element that is highlighted, the following information will show:

Label
Value
Traits
Identifier
Hint
User Input Labels

You can now see the accessibility tree information for that element! Not only that, you can also do simple manual checks to go beyond automation.

For example, in the image below, currently focused is a search icon in an application, and that icon button has a label of "ic search" with a trait of 'button'. Automated checks would say this is fine since it has a label, however the label itself is not sufficient as it does not properly describe its purpose and contains partial image name. This is the true power of the manual inspector!

Screen Reader Navigation

One of the more unique features of the "Inspection" portion of this tool is the ability for it to read out the content of the view. Using the "navigation" section, you can simply hit the 'play' button and it will read out all the content within the view with a screen reader.

You may be thinking to yourself, "Well what is the benefit here if I can just fire up voiceover and do the same?". If a developer is using this tool and doesn't have access to a physical device and only an emulator, then this can be a subtle substitute for screen reader testing! It also shows all the information for each element just like above, so developers can learn why something may not be announcing properly.

Myth 2: Automated Checks Lack

A true statement when it comes to automated accessibility, is that it will NOT get you to 100% of all issues. However, that doesn't mean that automation can't get you started down a path to make your content accessible.

The accessibility inspector has been thought to have "only having 3 checks" for accessibility, touch target sizes, dynamic type and contrast. The truth is, there are 7 automated issues it checks for:

Element Description
Contrast
Hit Region
Element Detection
Clipped Text
Traits
Dynamic Type

Most development teams don't know where to start when it comes to making their applications accessible. These simple checks can help them get started down that path and can begin to ensure accessible practices while developing.

Myth 3: No Reporting

One of the bigger reasons teams choose not to use the accessibility inspector is "it doesn't have the ability to export a report". That is true no longer! The accessibility inspector does have the ability to export the automated checks to a report!

Within the inspector, if you go "File > Save audit report as.." you will be able to save an HTML file version of the report with screen shots and all!

This can help development teams with:

Definition of done
Automated monitoring of applications
Reporting of bugs

Myth 4: Only Works with Simulator

Accessibility inspector does not only work with the simulator! Yes, you read this correctly. You do not need direct access to the code or the simulator to run the accessibility inspector against your application!

You can plug-in your iPhone, pick an application and start inspecting it using the "Inspection" tab or run an automated audit it right away!

In Summary

Accessibility Inspector gets a bad reputation for only being single use case tool. The fact is, it has so many more features to help development teams make their applications accessible. Using this tool daily in development can help build a culture that makes accessible applications from the start!

Mobile Accessibility Advent Calendar Part 3

Mark Steadman — Mon, 27 Jan 2025 13:31:20 +0000

Welcome to part three of the Mobile Accessibility Advent Calendar! In this post we will cover days 17 through 24!

Day 17 of the Mobile Accessibility Advent Calendar!

Let's talk assistive technology on Android! 

In the previous post, we talked about getting into the mindset of only testing with screen readers, in this case TalkBack The truth is there is a load of different assistive technologies that users use that you should be testing with to ensure you content is accessible.

What you should be testing with:   

TalkBack- The standard default screen reader with Android, that should be at the core of the testing you are doing.
Switch Access - Allows users to use an adaptive accessory to interact with their phone in customizable ways that make it easier to use.
Keyboard - Android tends to have more keyboard users. Android actually allows for developers to make their applications accessible with keyboard by having specific attributes in the code, which in turns makes it a bit more keyboard friendly. Keyboard is CORE to what is needed to ensure your application is accessible.

Day 18 of the Mobile Accessibility Advent Calendar!

Lets talk about tables!

One misconception in mobile applications developed in SwiftUI (iOS) and Android (View/Jetpack) is that tables announce the EXACT same way as they do in web. Announcing the column and the row numbers and each respective cells data that you are on.

In mobile, there is NOT a semantic table like this. There are tables that layout content, and even a table in iOS that is used for desktop applications, but they do not function like this. In order to properly create a table and get the associations, you have to customize the table you have created and add in the proper announcements. The label must include the row (if necessary) and column header text, along with the data text.   

Using this delivery table as an example: https://www.w3.org/WAI/tutorials/tables/two-headers/.

In mobile we would want the label for the first cell to announce as "9:00 - 11:00, Monday, Closed". You can add in the word Row, or Column, but for the most part a lot of users have advocated not to have that information in mobile applications.

Please ensure you take the time to make your data tables accessible for all! It can make a huge difference in making your application easier to consume for everyone!

Day 19 of the Mobile Accessibility Advent Calendar!

iOS Accessibility inspector that comes with Xcode has a bad rep. Does it have some bugs and quirks, absolutely. However, most of the accessibility community thinks it is only automated issues that it finds, and those are about 3 issues. The truth is, it is a robust tool that lets you inspect the application for both automated AND manual issues. Here are some super dope facts about XCode accessibility inspector:

You can connect your phone and inspect ANY application for accessibility issues. No access needed to the code.
It has a step through ability to see all the information in the accessibility tree (Traits, Labels, Hints)
Navigation inspector can show how a user with VoiceOver would navigate the application.
Run Audits that check for 7 automated issues:
- Element description
- Hit Region
- Contract
- Element Detection
- Clipped Text
- Traits
- Dynamic Type

Day 20 of the Mobile Accessibility Advent Calendar!

Orientation matters!  

A lot of mobile accessibility applications currently only work in portrait. When they need to work in both portrait and landscape. Landscape allows ALL types of users to be able to interact with your application how they want. Some users use mounts for their device, others like a large screen, some use keyboards and its easier for them to navigate and see with keyboard.

However, if you do not develop/design with both modes in mind, this can be a very heavy lift to fix up and ensure that it is accessible. Not only must it not just orient, it must also:

Not cut off any text or overlap content
Must still have proper navigation order
All actions must still function
Must work with screen reader

Day 21 of the Mobile Accessibility Advent Calendar!

(Photo credit droids on roids)

Have you ever used an application and tried to tap a button on the screen and you just cannot seem to be able to get it to work? Maybe it's the smudge on your screen, or maybe, its that the application you are using does not have proper touch target sizes!

iOS and Android each respectively have their own touch target sizes that each item that has an action must meet in order for it to work for ALL users.

iOS Dimensions: 44 X 44pt

Android Dimensions: 48 X 48dp
 

Day 22 of the Mobile Accessibility Advent Calendar!

The ability for any and all users to be able to resize the text on their phone is one of the best features of mobile devices. Allowing for users to adjust their text size can help a variety of different users be able to interact with your applications in ways they may not have been able to in the past. Unfortunately, there are still MANY applications that do not resize AT ALL, causing frustration that may make them leave your application all together. How can we ensure our applications scale?

Designers:

Ensure you include specs that show multiple levels of resizing content.
Ensure no text content is cut off using a trailing …
Minimum font sizes for body text, 17 pt for iOS, 16sp for Android Developers
In iOS ensure your application uses Dynamic type
In Android use Scalable Pixels (SP) instead of DP Is this everything? No, but it does help to start getting your application down the right path of properly resizing!

Day 24 of the Mobile Accessibility Advent Calendar!

Today I want to take an opportunity to shout out some of my favorite mobile accessibility presentations I have seen! These are all free to view and are great resources to use at your organization!  

Building Accessibility Android Apps w/ Jetpack Compose by Devanshu Chandra
Intro to Mobile App Accessibility by Rachael Yomtoob
Native Mobile Accessibility Testing by Jan Jaap de Groot
Mobile Accessibility Tools by Shafik Quoraishee

Day 25 of the Mobile Accessibility Advent Calendar!

We have made it to the end!! My final post will not be a new tip or trick, it will be an ask and a call to action.

Mobile accessibility has long since been an afterthought for a lot of people in the world. However, with the world turning more and more to using mobile applications, it is time for organizations and creators of mobile applications to make their content accessible.   At the end of the day, it doesn't take that much to make your application accessible. I have a challenge:

Designers:  

Use free annotations kits to properly annotate accessibility
Ensure color alone is not used to indicate state or contain valuable information
Ensure the application works in both orientations

Developers:

Use testing tools (iOS a11y inspector, Android google scanner)
Take advantage of the linters for iOS and Android
Learn to use a screen reader (Talkback and Voiceover) and test your application

Scrum masters/Product owners:

Prioritize accessibility in definition of done
Include accessibility bugs in sprint planning

This is not everything or every role, but even doing these simple things above can help turn the tide to ensure we start building applications with accessibility in mind.
  
Thank you for following #MobileA11yAdventCalendar all month for tips and tricks on #Mobile #Accessibility ! Lets make the mobile world a more accessible place for all!

Mobile Accessibility Advent Calendar Part 2

Mark Steadman — Mon, 13 Jan 2025 14:57:50 +0000

Welcome to part two of the Mobile Accessibility Advent Calendar! In this post we will cover days 9 through 16!

Day 9 of the Mobile Accessibility Advent Calendar!

Continuing from where we started from our Day 8 post, common terminology in iOS. These are web terms translated into mobile accessibility terms. Web is on the left, and mobile equivalent on the right.

Aria-label = .accessibilityLabel
Role/State = Traits
Heading = .isHeader
Page Title = .navigationTitle
Aria-hidden = .accessibilityHidden
Aria-live = accessibilityNotification.Announcement

Using just these simple common terms can help you make a connection that lasts with iOS developers and designers! In our next posts we will cover iOS and Android respectively.

Day 10 of the Mobile Accessibility Advent Calendar!

Continuing from where we started from our Day 8 post, this is common terminology in Android. These are web terms translated into their similar mobile accessibility terms. Web is on the left, and mobile equivalent on the right.

Aria-label = contentDescription
Role/State = Role/RoleDescription
Heading = semantics isHeading()
Page Title = TopAppBar title
Aria-hidden = isImportantForAccessibility
Aria-live = LiveRegionMode Polite/Assertive

Using just these simple common terms can help you make a connection that lasts with iOS developers and designers! Are there any others that you can think of??

Day 11 of the Mobile Accessibility Advent Calendar!

Designers can help ensure mobile applications are accessible, however, most designers don't know where to start in order to properly annotate for accessibility. There are two FREE Figma plugins that exist that your design teams can use to begin bringing accessibility into the design process.   

Include from eBay: https://www.figma.com/community/plugin/1208180794570801545/includeaccessibility-annotations
CVS A11y iOS Annotations: https://www.figma.com/community/file/1331647574396908226/accessibility-annotation-kit-for-ios

Day 12 of the Mobile Accessibility Advent Calendar!

Resource time!  There are 3 main resources that I tend to go back to over and over again when it comes to mobile accessibility. These are key resources that can help you with implementation guidance for fixing issues, what to avoid, and more education deep dives on multiple different types of mobile concepts and application types.

The iOS Accessibility Technique library created by Paul Adams

The Jetpack Compose Accessibility Technique library created by Robert Allen Henley

Appt.org by Stitching Appt

Day 13 of the Mobile Accessibility Advent Calendar!

One of the top issues seen in mobile applications, is the improper grouping of content. What do I mean by improper grouping? In Android and iOS applications you can create content and have the whole item be tappable, like the iOS settings menu. You can also create components such as cards that can have multiple different pieces of information in them, like in commercial applications where you have an image of the item, description of item, and the price.

By default, when creating components such as these each individual item is accessible one by one for screen reader users. This causes a very frustrating experience when navigating complex applications. So what's the solution? Group similar content together to make each accessibility focus point clear and concise for the user.

For good and bad examples of grouping see my article here: https://dev.to/steady5063/top-5-ios-mobile-app-accessibility-issues-pt-1-51g8
More information on how to group content in iOS: https://www.hackingwithswift.com/books/ios-swiftui/hiding-and-grouping-accessibility-data 
More information on how to group content in Android: https://appt.org/en/docs/jetpack-compose/samples/accessibility-group

Day 14 of the Mobile Accessibility Advent Calendar!

Question I am often asked is, "it seems like mobile accessibility is the right thing to do, but is there anything that is actually enforcing that my application be accessible?" or "All I see is things that say 'web' accessibility but nothing for mobile, so we are off the hook right?".

In the past year or so, it is no longer web that is being called out, it is mobile applications as well! So when anyone asks does the application need to be accessible, emphatically say YES! Besides from the question of WCAG (which we will get to in another post), there are things in law that now point to the need to have your mobile applications be accessible.
 

Oklahoma State Mobile Apps: https://adasitecompliance.com/oklahoma-agency-doj-settled-inaccessible-mobile-app/
DOJ Accessibility Guidance: https://www.ada.gov/resources/2024-03-08-web-rule/#the-reasons-the-department-set-specific-requirements-for-web-and-mobile-app-accessibility

Day 15 of the Mobile Accessibility Advent Calendar!

The daily conversation I have with folks in the mobile space is one of two questions:

"Where are the standards for mobile accessibility!?!?!"
"Does WCAG actually apply to mobile??"

The answer in short, WCAG does apply to mobile applications. Yes, before anyone gets up in arms and says the word "web" is literally in the title that doesn't make sense, it will. The principals that WCAG is built on are easily transferable to mobile applications.

Does every little thing within WCAG apply? Not necessarily. Are there resources and guidance in WCAG that are web based and can make it difficult to translate it into what is needed for mobile? Sure!  However if you are looking for a starting set of resources to help guide you in the right direction for guidelines there are a couple really good ones!  

BBC Mobile Standards: https://www.bbc.co.uk/accessibility/forproducts/guides/mobile/summary/
W3C (OLD) Accessibility Mapping: https://www.w3.org/TR/mobile-accessibility-mapping/

There are also some mobile specific standards (built on principal of WCAG but their own guidelines):

Evinced Mobile Standards (MCAG): https://getevinced.github.io/mcag/

Also, there is an awesome working group that is currently building a set of standalone mobile accessibility standards.

Day 16 of the Mobile Accessibility Advent Calendar!

Let's talk assistive technology! 

One mindset we tend to get into in mobile application accessibility is testing only with screen readers. In theory screen reader testing SHOULD catch most of the issues in your application, however to get a full picture of the accessibility of your app you need to test with multiple assistive technologies. The truth is there is a load of different assistive technologies that users use that you should be testing with to ensure you content is accessible. For this post, we will cover iOS!

What you should be testing with:   

Voiceover - The standard default screen reader with iOS, that should be at the core of the testing you are doing.
Switch Control - Allows users to use an adaptive accessory to interact with their phone by highlighting each item sequentially. More on Switch Control
Voice Control - Allows users to use voice to control iOS device. One of the common testing methodologies I suggest with this is saying "show numbers" and ensuring all the actionable items on the screen are accounted for AND function. More on Voice Control
Keyboard - Yes, you read this correctly. No it isn't an assistive technology per say, however keyboard users exist in iOS. To say that they don't would be a mistake, testing your application with keyboard and Voice Over on (and off) will ensure that multiple inputs can work with it.

Mobile Accessibility Advent Calendar Part 1

Mark Steadman — Fri, 03 Jan 2025 15:47:09 +0000

In the month of December, I created a mobile accessibility advent calendar across social platforms (LinkedIN, BlueSky). Each day I posted something about mobile accessibility to strengthen the knowledge of the a11y community, mobile developers and designers.

Day 1 of the Mobile Accessibility Advent Calendar!

If you ever are talking to an iOS dev or designer and say "this icon is missing a role of button" and they give you a perplexed look, it's because in iOS these are called "traits". When communicating with iOS devs, one of the biggest disconnects in Accessibility is talking the same talk. If you say "this needs a trait of .isButton", it will stick!  

Day 2 of the Mobile Accessibility Advent Calendar!

Did you know, that Android comes with its own accessibility testing framework by default? The Accessibility Test Framework (ATF) is googles out of the box testing library that runs at multiple levels, including linting and UI automated testing.
  https://developer.android.com/guide/topics/ui/accessibility/testing#analysis 

Day 3 of the Mobile Accessibility Advent Calendar!

If you are developing your application in SwiftUI, you are probably using SwiftLint to check your code for issues as you develop. Did you know that you can activate two accessibility rules within library? Its super simple to turn on and can help your team check for accessibility issues as you code! Here are the two rules:

Accessibility Trait for Button - All views with tap gestures added should include the .isButton or the .isLink accessibility traits

Accessibility Label for Image - Images that provide context should have an accessibility label or should be explicitly hidden from accessibility

Documentation (Search accessibility): https://realm.github.io/SwiftLint/Guides.html

Day 4 of the Mobile Accessibility Advent Calendar!

One of the most common issues in mobile applications is the lack of proper headings. Headings are needed in mobile applications to make it easy for users to navigate between large chunks of content. Without them, mobile applications can become cumbersome for users to navigate with Voiceover and Talkback.

The dope part, they are available in both platforms and yes users do use them to navigate your application! Simply give the heading text the proper trait of .isHeading in iOS and accessibilityHeading=true in Android.

For more information on headings for iOS and Android visit:  https://www.magentaa11y.com/checklist-native/headings/

 

Day 5 of the Mobile Accessibility Advent Calendar!

In the previous post we discussed headings and how they can make applications easier to navigate for users who use Talkback in Android and Voiceover in iOS. The typical navigation of users in both platforms is to swipe right with their finger to navigate down the view and swipe left with their finger to navigate backwards. Each time a user swipes, each item in the view gains accessibility focus. This of course can be cumbersome without a way to jump around large chunks of content.

This is where the Rotor in iOS and Reading Controls in Android come in handy. Both are features that allow for users to quickly access features of an application such as headings. When a user selects "headings" to navigate, they then can swipe with their finger up or down to navigate heading to heading! There other forms of actions and navigation that can be done using both, for more information click on one of the links below!

iOS Rotor: https://dequeuniversity.com/screenreaders/voiceover-ios-shortcuts
Reading Controls Android: https://dequeuniversity.com/screenreaders/talkback-shortcuts

Day 6 of the Mobile Accessibility Advent Calendar!

Be careful when using hints!

Hints can be used for extra information on content in mobile applications, however, hints should not contain ANY vital information for a user.  

Users of TalkBack and Voiceover have the option to turn off hints. There are a large amount of users who have this turned off, as hints are misused and may give more information than needed in mobile applications. The one misconception in mobile is that hints behave like aria-describedby in web, and is always read. Therefore, a hint really should only be used when it is extra context for a user and not VITAL context for them to understand the control.

Android Hints: https://appt.org/en/docs/android/samples/accessibility-hint
iOS Hints: https://appt.org/en/docs/ios/samples/accessibility-hint

Day 7 of the Mobile Accessibility Advent Calendar!

Hybrid applications combine Web and Native development into one singular item. These applications can be built with a web framework such as Angular, Vue OR they are their own language entirely like Flutter or React Native.

The major disconnect in the accessibility community is understanding the type of application that is being developed. Not all mobile applications are developed in SwiftUI/UIKit (iOS) or View/JetPack(Android). Knowing how the mobile application you are working with is being built can help you be able to give proper information on how to fix specific issues in the application itself.

The big question though is, do they need to adhere to the same standards for mobile accessibility? The answer is YES! Even though they may behave more similarly to web content, users would expect them to behave as much as possible like a mobile application!

Day 8 of the Mobile Accessibility Advent Calendar!

Terminology is key to making a connection with mobile designers and developers. One of the big disconnects in the mobile community, is a lot of us come from a web accessibility background, and it can get really hard trying to tell mobile developers how to fix issue when what we say doesn't connect with what they know.

The next couple of posts will cover key terms in mobile and the equivalents in web. Think of this as a terminology cheat sheet! Lets first start with common terms between iOS and Android both:  

Web Page = View
Main Navigation = Navigation/System Bar
Aria-describedby = Hint
Focus = Accessibility Focus
Tab Order = Swipe Order
Resize Text = Scale

Even just these 5 common terms can help you make a connection that lasts! In our next posts we will cover iOS and Android respectively.

Conclusion

Stay tuned for part 2 very soon!
Follow #MobileA11yAdventCalendar on LinkedIn and BlueSky to see more posts from the last month!

Top 5 iOS Mobile App Accessibility Issues Pt 1.

Mark Steadman — Thu, 01 Aug 2024 15:16:11 +0000

Over the last few years, I have been asked more and more "Mark, what are the most common issues in mobile applications". Normally I would respond with what I know, however lately I have began to ask myself "What is the current state of mobile accessibility" and "are the common issues still the same?"

Flash forward to the spring, in which I did a workshop for an accessibility conference called AccessU (If you haven't heard of it check it out because it is awesome!). The workshop was titled "Simplifying Mobile Accessibility", where we take the complex topic of accessibility in mobile and break it down so everyone can easily fix the bulk of their issues.

For this workshop, I decided to do my own personal study of 10 iOS and Android mobile applications to see what were the most common accessibility issues in those applications, and what are general trends between all of the apps.

Now, its time to share some of that information with you all, lets dive in to the top 5 iOS application accessibility issues!

The Study

Before I dive into the issues, I wanted to take a moment to explain the different applications I tested and how I tested them. Do know, for the purposes of this article I will not share the EXACT name of the applications in the study, just the industry/category they are in.

When deciding the 10 applications to test, I chose 3 retail applications, 3 food or food service applications, 3 travel applications and 1 social media applications. To pick which ones of each category, I simply went to the app store and pick the top ones listed.

For testing of each application, I tested with Voiceover, Voice Control, Switch Control and Enlarged font sizes. For those wanting to know how to test with each I have linked resources right here:

The Issues

Whew, okay finally we can get into the meat of this article; the issues! Lets dive into the first couple of commons issues seen in the sample of applications tested!

Missing Traits

This one may come as no shock to anyone reading this, however around 26% of the total issues found, where actionable items missing a proper trait. For those not familiar with iOS, think of a traits as the roles for particular items (like ARIA roles in web).

Many items that were actionable were missing button or link traits, which makes it impossible for Voiceover and Voice Control users to know if the item has an action tied to it!

Remediation Tips

First and foremost, if you can use semantic/native elements, USE THEM!! Anytime you use a text element or elements that are not native elements, you do not get the accessibility baked in with it.

Second, if you must use an element that is not native/semantic then you can do something similar to the following to add a trait to the element to get it to announce properly.


 Text("A11y is Awesome")
            .onTapGesture {print("The gesture tapped")}
            .accessibilityAddTraits(.isButton)

You can also remove traits and then add a trait back to an element. For example, if you use an image and make it actionable but want it announce as "button".


Image(systemName: "heart")
    .accessibilityRemoveTraits(.isImage)
    .accessibilityAddTraits(.isButton)

Improper Grouping of Content

Coming in with around 20% of the issues found, Improper grouping of content. This one may confuse folks a little. What does Mark mean when he says "improper grouping of content"? In iOS applications you can create rows of content and have the whole item be tappable (think the iOS settings menu). You can also create components such as cards that can have multiple different pieces of information in them.

By default, when creating components such as these each individual item is accessible one by one for voice over users. This causes a very frustrating experience when navigating complex applications. So what's the solution? Group similar content together to make each accessibility focus point clear and concise for the user.

Bad example:

In this example, we have a product with an image then under that the name, the price and price per. Notice in this example, that each individual item in the component gets an accessibility focus which is cumbersome for Voiceover users

Good Example:

In this example photo, which is the same layout as above, the item is grouped together as one accessibility focus stop that allows for easy navigation and consumption of information!

Remediation Tips

To group content, it is relatively simple. Take the component or content that needs to be grouped and group it using the .accessibilityElement(children: .combine).


VStack {
    Text("Dunkin Donuts Coffees")
    Text("Price: $5.00")
    Text("Quantity: 2")
}
.accessibilityElement(children: .combine)

In Summary

This is only part 1 of the top 5 issues in iOS applications, there are still 3 more issues to cover! However, if you are a mobile developer take the time to look at your application for the two issues discussed in this article and see if your app has them. If they do, fix em up! Accessibility only helps extend the reach of your application so why not take the time to make it usable for all?

Maximizing Automated Accessibility Results

Mark Steadman — Thu, 16 May 2024 20:01:33 +0000

When a development team sets up their UI automation tests with accessibility, they tend to think they are done!

"We included accessibility as part of our UI testing process, so we can now track how accessible we are!" However, if you asked most dev teams what they plan to do with results, the answers can be a mixed bag.

If your development team wants to truly build and sustain accessibility in their environment then you need to maximize the value of the results from accessibility testing! Lets dive into how!

Consistency is Key

The first thing consider to maximize your results is consistency. There are many accessibility libraries that exist and sometimes it can be confusing which one to start with. If you choose a particular ruleset such as axe or pa11y for the tests, then stick with it!

Some development teams will use one ruleset for one level of test and entirely different one in a different level of test. This can cause confusion and different results. It may seem simple, but different results can make learning about accessibility difficult for some developers who parse the results. One ultimate goal is to educate developers as they code, and having those consistent results can help ensure this!

Enforce It

If your development is up and running and fully using automated accessibility in UI tests, the best action to take is to enforce the issues that arise from the tests.

Code Reviews

One way in which accessibility in the development process can be improved is through code reviews. A lot of development teams currently have an "honor system" for automated tests or manual accessibility testing, in which the developer claims they did those steps. Which is why they tend to continue to have issues and not see a downward trend.

Adding enforcement of critical and serious accessibility issues from automated tests in code reviews can help ensure that teams fix the issues proactively before they check in code!

Github Actions (Quality Gates)

Another form of enforcement is through github actions! Github actions allow you to run specific actions on commit of new code.

For example, I am a developer who creates a component. I finish and I create a PR. If your tests are properly setup, a github action will run and check the accessibility of the new content you just created!

Github actions are simple and effective to setup and can easily make enforcing the automated checks on every single PR!

For an example of a working Github Action, you can visit my personal Github accessibility page!

Linting

Linting is another simple way to enforce accessibility issues being fixed before release. Although separate from the UI automated tests, linting checks are so simple that they can help your dev team keep issue counts down!

Accessibility linting has many benefits that can greatly improve your development team, including:

Catching issues as you build HTML content
Building accessibility knowledge for your developers
Allows your team to build an accessible gate on commit
Customizable to the framework you are developing in

Reporting Results

The final thing to maximizing results is gathering reporting from your tests. Most development teams tend to create a standard check and check if it fails. However, with accessibility defects there tends to be more data needed in order to fix issues.

There are a number of ways to ensure you get the most data out of the tests your create.

Axe HTML Reporter - Generates a nice report from the axe results objects for teams to use to see the state of the content tested.
Axe pretty print console logger - A console logger that puts the results in a nice summary table.
Jest/Mocha HTML report - You can take advantage of out of the box reporters from test frameworks like Jest/Mocha if you properly label your test cases

In Summary

If your development team has fully integrated accessibility testing as part of their UI automated tests, then it is time to get the most out of those results. Using the suggestions above, you and your team can build a culture of developing content with accessibility in mind!

Creating Effective Automated Accessibility Test Cases

Mark Steadman — Tue, 14 May 2024 11:03:14 +0000

One of the biggest fallacies in UI testing, especially when it comes to accessibility testing, is simply just making everything into a checkbox. Did we do the minimum UI testing on that component? Check! Did we do accessibility testing? Check!

The tests that are written may not be the most thought out or effective for actually testing the UI. This can cause UI bugs to persist because the tests do not have the proper depth or requirements.

UI accessibility testing also is at fault for this. The typical phrase heard is "Yeah we do accessibility testing! Its fully integrated and we use it each time our tests run!". However, most development teams continue to push out automated accessibility issues.

How can we improve our accessibility UI tests to more effectively know the issues in our code?

Proper Testing Structure

Instead of rushing to make a test case that says "accessibility check", there are ways to structure and build regression tests for more effective accessibility testing.

One to One UI Tests

There is a principal in UI testing that says for each piece of UI there should be a test case to follow. Meaning one piece of UI, one test case. This ensures that each component or piece of HTML has a particular set of regression tests.

We can apply this same principal to the accessibility test cases we setup. Instead of just simply installing axe-core or pa11y and running a scan at a high level, we can effectively place the scans for better coverage.

For example, if we have a React component, that has a set of unit tests for its UI functionality, we can create a test case for that component like so:

describe('Footer Component', () => {

  test("Funtionality - Component has loaded", () => {
    render(<Footer />);
    expect(screen.getByRole("heading")).toHaveTextContent("Contact Us");
  });

  test("Functionality - List number", () => {
    render(<Footer />);
    expect(screen.getByTestId("footList")).not.toEqual(null);
    expect(screen.getByTestId("footList").childElementCount).toBe(4);
  });


  test("Accessibility - base render",async () => {
   const {container} = render(<Footer />);
   const results = await axe.run(container)
   expect(results.violations.length).toBe(0);
  });

In that same test spec, if the UI test case expands and collapses the component, you could run a scan in each of those states and collect the results for each state of the UI. The goal is to make the accessibility test apart of the testing structure, but also effectively show the issues!

Multiple Levels of Test

If your development teams multiple levels of test such as Unit and Integration level testing, you should include accessibility testing at both levels.

Why? If you test only in your unit or component UI tests, you will miss more issues that exist when those component begins interacting on the page together.

An example of a component that would not have any automated issues in unit test but would in integration would be a component that has a "more info" link. If that component is used multiple times on the page, then in integration testing you would find multiple links with the same text!

Separate Accessibility Suite

Different than having your accessibility tests as part of your test cases, you can have a separate suite of UI tests for accessibility. Development teams that are newer to including accessibility in their UI tests tend to go this route simply because their suite may be too complex to add it in or its easier for them to get it setup.

Although not as effective as including in your current testing structure, there are benefits to creating a separate set of tests for accessibility only, which include:

More streamlined reporting on the state of accessibility
Easier to see results
Easier to create JIRA bugs

To do this, in your project, create a separate accessibility tests folder and create either a single spec or specs broken down by business logic (groups of pages, etc). Then in your test describe give it a name similar to "Accessibility of " and then test each page in the experience.


describe("Accessibility of Space Jam",  () => {

  test("1996 Page", async () => {
    await pa11y('https://spacejam.com/1996').then((a11yResults) => {
        expect(a11yResults.issues.length).toBe(0)
    });
  });

  test("2000's Page", async () => {
    await pa11y('https://spacejam.com').then((a11yResults) => {
        expect(a11yResults.issues.length).toBe(0)
    });
  });

});

Add Accessibility Regression Tests

Simple javascript libraries can give you easy, static accessibility results. However, you can go a step further and include specific regression tests for accessibility issues.

When writing your teams test case, instead of just including a simple axe or pa11y test, build an accessibility regression test as part of your UI requirement testing.

Let's take a look at an example using Cypress and a component that expands and collapses. I can write a simple accessibility regression test that ensures that I am properly setting the aria-expanded true/false like so:


   it('A11y - FAQ proper expanded state', () => {
      cy.get('#toggle').invoke('attr', 'aria-expanded').should('eq', 'false');

      cy.get('#toggle').trigger('keydown', {
         key: 'Enter',
       })
      cy.wait(150);
      cy.get('#toggle').invoke('attr', 'aria-expanded').should('eq', 'true');

      cy.get('#toggle').trigger('keydown', {
         key: 'Enter',
       })
      cy.wait(150);
      cy.get('#toggle').invoke('attr', 'aria-expanded').should('eq', 'false');
  });

Now these test cases can be apart of the standard requirement testing. The only thing to ensure is in the test the title includes "A11y" or "Accessibility" to ensure easily findable results.

In Summary

It's time to get past the "we included accessibility tests" that get little to no results and more effectively create test cases that allow your development team to fix more accessibility issues now! Using the suggestions above your team can easily begin to maintain an accessible application for years to come.

Choosing Your Accessibility UI Testing Library

Mark Steadman — Mon, 13 May 2024 02:24:14 +0000

Where To Start?

If you are a web developer looking to level up your teams UI automated tests to include accessibility what is the first thing you do? Google search of course!

When you google search though, you may find yourself a bit overwhelmed with where to start. There are numerous different accessibility testing libraries and all them seem to work their own way.

This is where developers tend to stop and go, "Well this is a lot, maybe ill add it later". That later, unfortunately, never comes.

Let's break down how you can chose the best testing library for your development team!

What Are My Options?

There are multiple different packages that you can install into your project that allow you to include accessibility in your UI tests.

The ones that I highly suggest for usage in UI testing are as follows:

Axe-core - Axe is an accessibility testing engine for applications and HTML based content. It is the most powerful rules engine for accessibility and contains the MOST integrations on the market. Examples of integrations include:
- Playwright
- Cypress
- Puppeteer
PA11y - A command line node.js library that runs HTML code sniffer by default but also can run the axe-core rules as well!
Google Lighthouse - Node CLI package that runs various checks on your application, but also includes accessibility testing as well!
Wave by WebAIM - The WAVE extension is one of the most powerful extensions for accessibility testing. The package allows you to include that powerful testing in a CLI.

All of these work differently in their own respective ways. So how do you know which one to choose?

Making The Best Choice

When deciding which accessibility testing library you should use, it comes down to one thing. Ease of integration!
Whichever library fits into what your development team is doing for UI testing, should be the one you use.

For example, if your development team does integration level testing or end to end testing, then PA11y or Wave is a great library to use as it will fit directly into integration testing with its CLI or NodeJS commands.

An example of pa11y running:


  test("Space Jam is accessible", async () => {
    await pa11y('https://spacejam.com/1996').then((a11yResults) => 
      {
        expect(a11yResults.issues.length).toBe(0)
      });
  });

If you are already using a previous testing library like Lighthouse, then simply ensure the accessibility tests are running and are visible! They should be included in the output results.

Finally, if you want a specific integration into a testing framework such as Playwright or Cypress, use an axe-core integration. They are extremely easy to integrate into your current testing framework and can have you up and running in no time!

Example using @axe-core/playwright


test("is accessible", async () => {
  const page = await context.newPage();
  await page.goto('https://www.spacejam.com/1996');
  const results = await new AxeBuilder({ page }).analyze();
  expect(results.violations.length).toBe(0);
});

In Summary

Choosing a library can be overwhelming to start. However, with a simple understanding of the top options available, you can get your development teams UI testing up and running with accessibility tests in no time!