I’m more of a web person than an app person, but my clients sometimes need to publish statements about their apps. Accessibility is important to a large part of app users, showed Dutch web consultancy Q42: in over a million app users, they saw 43% use accessibility settings.
If app stores would have a field for accessibility statements, this would be good for users, organisations and developers, plus it highlights accessibility as something to compete on.
What is an accessibility statement?
An accessibility statement shows users that you care about accessibility and helps them understand what the expected level of accessibility is on your website or application (see also: Developing an Accessibility Statement).
Sites and apps that fall under EU Directive 2016/2102 (Article 7, section 1) require an accessibility statement, in a specific format. Other sites and apps can also benefit from some form of accessibility statement.
What is included in an accessibility statement?
In their accessibility statement, website or application creators declare whether their app is fully, partially or not accessible. If one of the latter two, they also list what the known issues are. Commonly, there is also information about when the website or application plans to address each issue.
Accessibility statements also include evidence of their accessibility claims. Usually this is a full WCAG conformance evaluation report, following a methodology like WCAG-EM. But accessibility does not equal WCAG conformance, you might say. This is true, it is ‘just’ a baseline. Yet, there is no other document with such a widely agreed baseline, so it is best to use this one.
Accessibility statements can also contain a feedback mechanism (they must, if published in a country that has implemented that EU Directive). Feedback mechanisms let people find out how to request content in a format that is accessible to them (e.g. can I have that untagged PDF as a Word document?), and where to report accessibility issues.
App stores have fields for privacy statements
Both the Apple App Store and the Google Play Store have a meta field available for privacy statements.
Google does this, because they care about user privacy. They write in their Google Play Safety Section blog post:
At Google, we know that feeling safe online comes from using products that are secure by default, private by design, and give users control over their data.
It’s framed as letting developers showcase how well they do on privacy:
This new safety section will provide developers a simple way to showcase their app’s overall safety.
I, for one, applaud this effort. User privacy is super important and explaining privacy features is helpful. A standard way to do it helps users find this information more easily.
I would say we can apply the same thinking to accessibility. As mentioned earlier, app users require accessibility. It is likely they will want to find accessibility information easily. App developers and designers work hard on ensuring their app’s accessibility, so why not give them a way to showcase that too?
Why app stores need accessibility meta info
Accessibility meta info in app stores would be good for several reasons:
- helps users understand the accessibility of an application better, and learn easily and consistently about where to file accessibility bugs or request accessible versions
- helps organisations comply better with EU Directive 2016/2102, which says they should display an accessibility statement
- helps developers show their commitment
- renders accessibility as yet another aspect to compete on for application developers, because many consumers will use this to make purchasing decisions
App stores can be a helpful proxy between users and app creators. The vetting mechanisms and categorisations (try to) filter out low quality. They also make it easier for users to find what they need. This is why they provide filters for user-oriented features. If that’s great for privacy, it would be great for accessibility, too. Please, app store makers? 🙏
Thanks Peter and Matijs for feedback on an earlier draft. Thanks do not imply endorsements.