Desktop & Mobile Applications

New to using this roadmap? Start on the Digital Accessibility Compliance Roadmap page to understand the structure of the roadmap, how to use it, and how to get help.

Desktop and mobile applications are hosted and built on a variety of different platforms at U-M and across many different contexts. A few of the many features that can help make applications more accessible are keyboard navigation, form controls, high contrast, and text alternatives.

Open book and shining lightbulb icon

Learn

Who is responsible?

UX designers and developers of mobile and desktop applications.

What do you need to know?

Designers:

Developers:

Document inspected with magnifying glass icon

Review

Who is responsible?

Anyone who designs or develops desktop and mobile applications for university services, courses, and projects.

Process for review

Step 1: Inventory your applications

Use the application inventory spreadsheet (or create your own system) to track which applications you are responsible for. Note application names, URL locations (if applicable), whether they are currently in use, and whether they are up to date (i.e. pending new version release or anticipated design/content changes). Consider removing applications which are no longer in use. For applications currently in use, note the front-end framework, whether it is public-access or U-M login only, and whether you have edit access to the application (if not, list the contact person that does). This information will guide the approach to remediation.

Step 2: Assess use

  1. Is the application still in use? If not, consider archiving it if you are the owner.
  2. Does the application meet any of the following criteria? If so, mark “high priority” for remediation.
    1. Critical for U-M employees or students to access/engage with a university service, and/or
    2. Used by a high volume of users, and/or
    3. Available for public use.

Learn more about how to determine accessibility risk for digital applications and other IT.

Step 3: Prioritize for remediation

Applications that don't require remediation:

  • Applications that are already archived, or are soon to be sunsetted.
  • Applications that have recently been reviewed for accessibility by the ITS Accessibility team or the Disability Equity Office, with no changes made to the content, design, or components, and no known/reported access barriers.

For all other applications, prioritization recommendations are below.

High priority: Applications that are marked "high priority content" in step 2B or that you have received accessibility complaints about.

Lower priority: Applications used infrequently or by very few people, with no known access barriers reported.

Step 4: Assess accessibility

Run an accessibility scan of the application. There are a few different tools to do this depending on the operating system: BrowserStack (iOS and Android mobile), Xcode Accessibility Inspector (iOS only), Android Accessibility Scanner (Android mobile only), AccessibilityInsights (for Windows desktop only). If you are seeing issues flagged, the application needs to be remediated.

Tools for reviewing and remediating web-based applications can be found on our Websites and Web Applications Roadmap Pathway. 

Disclaimer: Automated accessibility checkers cannot find 100% of issues (usually only 40-80%). They provide a good starting place for identifying access issues across large applications, but always require some level of manual verification. This is especially true for applications, as they often feature forms, custom design elements, and complex components.

Hammer icon

Remediate

Who is responsible?

Teams will need to determine who is responsible for remediating applications. Those that maintain content for applications can be responsible for adding alt text to visuals, descriptive hyperlinks, color contrast, proper use of headings, and text formatting and layout. 

Access issues with components, forms, page layout and navigation menus likely need to be addressed by the application developer. Issues intrinsic to stylistic elements or built-in designs need to be addressed by the designer. If the application is hybrid, and therefore, partially relies on components or design elements from an external platform, the third-party vendor is also responsible for remediating their own inaccessible products. When determining the root cause of an access issue, identify whether it falls within the scope of aspects you can adjust, or if it is a built-in or pre-set part of the platform, in which case it should be reported to the vendor.

What standards do you need to meet?

Apply Technical Standards

Mobile and desktop applications should follow the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA standards, which are referenced in U-M's Electronic and Information Technology SPG and the ADA Title II federal regulations. 

Because these guidelines were conceived specifically for web-based content, it may be helpful to look over W3C's guidance on applying WCAG to mobile apps and guidance on applying WCAG to non-web IT (which includes desktop applications).

Avoid Common Barriers

Common desktop application barriers include:

  • Inaccessible forms and controls (forms and input fields that lack proper labeling, focus indicators, or instructions),
  • Unclear or inconsistent navigation across pages, and
  • Excessive animations or transitions (that users cannot turn off).

Mobile applications are impacted by the same barriers, with a few additions:

  • Inaccessible touch targets with small or closely spaced buttons/links (make sure intuitive gestures like swiping to navigate or pinching to zoom are compatible),
  • Incompatible with built-in system voice control functionality, and
  • Lack of control over haptic feedback (give users the option to turn haptics on/off, if included).

What could a remediation workflow look like?

Prepare

Start by reviewing best practices for applications:

Then test applications for accessibility, and keep track of issues or access barriers found. There are two types of tests to run:

  1. Automated scan: Can detect some types of accessibility issues, typically surface-level problems for non-web-based applications (e.g., color contrast, alt text, heading hierarchy…).
  2. Manual testing: It is critical for mobile and desktop apps to be manually tested to some degree, either directly with a screen reader or by checking for specific barriers.

Run Automated Scans

Tools that perform automated scans are listed under the “What tools are available?” section below. Reference associated documentation from the developers for how to use the tools and interpret results.

Do Manual Testing

  1. When conducting a review of an application, use the Technical Review Template to log issues (or create your own). It is often helpful to test by workflow, or the series of steps that a user will take as they interact with the application. When deciding which test cases to start with, think about which workflows are most critical to the function of the application, as well as which are most frequently utilized. As you step through each page or component the user would interact with, review it for the applicable accessibility tests.
  2. Follow the tests laid out in Testing for Web Accessibility - Global Tests. Not all tests are applicable to desktop applications, but a majority include relevant criteria to check for. Use the Specific Tests for applications with forms, font icons, or SVG graphics. These tests not only help identify access issues, but explain expected behavior for elements to meet WCAG success criteria (i.e. "fixes").
  3. For more extensive accessibility testing, it can be useful to also run through user workflows with a screen reader. Desktop applications can be tested with NVDA or JAWS on Windows devices, and VoiceOver on Mac devices. Mobile applications can be tested with VoiceOver for iOS devices and TalkBack for Android devices. Refer to the WebAIM screen reader guides under "What tools are available?" below for more help with using screen readers to evaluate app accessibility.
  4. Many access issues can be resolved at the content-level by content managers or editors. These include using semantic headings, formatting lists and tables correctly, adding alt text to images and long descriptions to complex visuals, providing descriptive hyperlink text, selecting text colors with sufficient contrast and legible fonts, and captioning videos.

Refer to the Accessibility Checklist for Mobile Applications for a comprehensive list of success criteria.

What tools are available?

Automated Tools:

Manual Tools/Resources:

Using Screen Readers to Evaluate Accessibility:

Bar chart icon depicting upward trend

Monitor & Improve

Who is responsible?

Application designers and developers are responsible for integrating accessibility practices into their workflows, in both design and functional testing, rather than relying on retroactive testing/remediation.

How to establish a monitoring plan

Your inventory of applications should be periodically reviewed and updated to determine if remediation work is needed. It is a good idea to routinely review your applications for accessibility a few times a year, but at the very least, they should be reviewed each time a substantive change is made to the application (e.g., new functional components, page layouts, or features), depending on the scope and scale of that change.

When new content is added, the impacted section should be checked for accessibility. When a new component is introduced, the design and functionality should be thoroughly tested for accessibility, as well as the template it is added to (if applicable). When the navigation structure is altered, menu components across the entire application should be tested for accessibility.

How to integrate improvements into workflows

There are many ways to proactively integrate accessibility best practices into your desktop and mobile application workflows.

  1. Choose accessible front-end frameworks for developing applications. This makes it easier to rely on using pre-built components and address access issues with the vendor as they arise.
  2. Implement accessible design from the start. In new applications, designers and developers can implement accessible design practices as they create, and drastically decrease the need for remediation work later on.
  3. Incorporate accessibility into existing review processes. Include accessibility testing as part of your development process and design process—there is no need to separate it from typical design review or functional testing. “Shift left” to integrate it into every stage of review, rather than only including accessibility reviews at the very end.
  4. Leverage automated scanning tools. Install accessibility scanning tools that make it easier to iteratively check apps as you're developing them.
  5. Report accessibility barriers as you encounter them. If you identify potential access barriers on an application your team/dept is responsible for, contact the owner, and/or the designer/developer, to remediate the issue. If you encounter an access barrier on a U-M application, but aren't sure who to contact, you can always report an access barrier with ECRT.

Get Help

For assistance using and adapting the roadmap or navigating compliance concerns, request a Disability Equity Office consultation.

For technical assistance with U-M supported digital accessibility tools or questions about remediating complex formats, contact the ITS Digital Accessibility team.