Accessible cross-platform UI standards

The Standards

Never rely on settings or modes to meet basic accessibility standards
Settings can and should be used to further enhance an already accessible experience
Don't associate all accessibility features with assistive technology

Settings require awareness, ease of discovery and an understanding of how they could help. Don't assume people who could benefit from Accessibility settings are aware they exist
Web or Webviews within apps cannot reliably use OS settings to meet accessibility standards. If you rely on accessibility settings in app, shared cross-platform design is not possible
Adding accessible UI only when a screen reader is detected buckets unrelated disabilities together. Avoid making an “accessibility view" and make your default experience accessible.

All websites, web apps and web-views should exceed WCAG 2.2 AA
WCAG2ITC provides a "notes in the margin" approach to how WCAG 2.2 can be applied to non-web software and documents
The European Standard for Accessibility excludes 6 WCAG success criteria (and modified 13) for applications. Read about this on Appt.org - EN 301 549
Aligning to a universal standard means Design and QA will have less ambiguity about what they should audit native apps and web against

Take the best and ignore the rest
Recognise when operating system design decisions don’t meet high enough standards and develop your own

Native operating systems have some amazing accessibility features that are a great enhancement to any experience
You’ll benefit from yearly updates and improvements using iOS and Android patterns
Google and Apple don’t always get it right when it comes to accessible UI. Take the responsibility to not pass on these mistakes to your users

Content and interface design should be as simple to comprehend and use as possible. Regularly question every element on a screen and actively remove as much as you add
Avoid novelty compromising usability

Everything on the screen is something a user needs to think about
Unproven or elements of little value are often left in interfaces indefinitely
Know the right time to be playful or expressive. Opportunities for Delight and Desirability are built on a strong foundation of being Functional and Useful

Native apps and websites need to adapt to personal settings. That could be increasing font size, using custom styles or turning off animations
When we have themes, such as Light and Dark mode, they should meet the same accessibility standards. The only exception is when the user has asked us not to

Light and Dark themes are not explicit accessibility features, they should both meet WCAG 2.2
Having a single mode that is accessible will exclude people that cannot use that mode
Over a third of people increase their font size or use an accessibility feature
We don’t get to choose how people view our websites and services

Elements that look the same should behave the same
Make sure people have a genuinely consistent experience, not just a visually similar one
Think about keyboard interaction, how elements are described or how errors are handled
When working with third party suppliers and white label products we need to ensure that they meet these standards too

We need to actively promote design is “how things work” and not just what it looks like
Organisations under estimate the accessibility issues caused by “skinning” websites
Inconsistent keyboard interaction is significantly more impactful to a user than the wrong colour or wrong border radius
People that move between platforms or domains should have a predictable experience

Strive to create native experiences to whatever platform the customer is interacting with
When you mix technology, be honest about it

Webviews, even in “Software” need to be treated as websites. They cannot access many accessibility features of mobile operating systems
The design of web and native elements will need to be different in a number of places
People should be able to recognise when they are in a webview. Their interactions and audible cues will be different and they may need to adjust how they browse

The majority of websites and apps are not accessible
Don't base your standards on other companies or competitors. Let them to base their standards on you
Be ok with parts of the design being different when they have to be

WebAim surveyed the top 1 million home pages and 56,791,260 distinct accessibility errors were detected—an average of 56.8 errors per page
If we base "good" on organisations that do the bare minimum for accessibility, we add to the problem
The standards organisations say they will meet rarely align with the reality
You can always, always, always do more