Apps
Everyone uses apps on mobile phones and tablets in their daily lives. Many apps for mobile phones and tablets need to be universally designed. For example, apps for banking services, booking appointments, and buying tickets have to comply with universal design requirements.
The regulations apply to many apps
The requirements apply to web solutions. Web solutions include both websites and many apps for tablets and mobile phones. Apps that need a web connection to be used after they have been downloaded must comply with universal design requirements for ICT.
Examples of these includes the apps for Ruter, Vipps, Finn, Avinor, SAS, Posten, Yr, Hotels.com, and apps for mobile banks and the administration of mobile phone subscriptions.
The requirements for apps are WCAG 2.0
Apps must comply with the same requirements as websites – 35 minimum requirements in WCAG 2.0.
All of the requirements are not necessarily relevant for a specific app. The requirements that actually apply in practice will vary in line with the app’s functionality and complexity. The requirements in WCAG depend on the type of content and if the app includes the content type, you must comply with the requirements.
Organisations that use apps in their contact with the public and customers, and app providers, should determine and document the requirements or parts of requirements in the standard that are not applicable.
As far as the practical use WCAG 2.0 in apps is concerned, we refer you to W3C’s document Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile.
The latest published version is from February 2015. The newest version of the document is W3C’s Editor’s Draft from December 2018.
The document shows how WCAG 2.0 is relevant for apps and discusses which characteristics should be taken into consideration when you use WCAG 2.0 for apps or other mobile interfaces.
Overview of the requirements in WCAG 2.0 that are applicable to apps
Within each requirement, you will find information about relevant suggested solutions and examples (in Norwegian).
- 1.3.1 Info and Relationships.
- 1.3.2 Meaningful Sequence.
- 1.4.3 Contrast (minimum).
- 1.4.4 Resize text.
- 2.1.1 Keyboard.
- 2.1.2 No Keyboard Trap.
- 2.4.3 Focus Order.
- 2.4.4 Link Purpose (In Context).
- 2.4.7 Focus Visible.
- 3.2.3 Consistent Navigation.
- 3.2.4 Consistent Identification.
- 3.3.2 Labels or Instructions.
Interpretation and test rules for apps
The common denominator for the Authority’s test rules for WCAG 2.0 is that they are geared towards websites. The Authority has not published interpretations of the requirements, checklists, or test rules for apps.
The Authority is in the process of developing test rules for apps. These are not currently suitable for volume testing, publication, and reuse. They will be published, although this will take some time.
The interpretation of the requirements and many of the test rules for websites can, with certain adaptations, be used to test the universal design of apps. You must take account of the fact that the technology for apps differs from the technology for websites, which will affect how a requirement is tested.
As of today, no common approach has been developed to test apps and universal design with techniques and frequent errors, either nationally or internationally. We expect a common European test methodology to be released for apps because apps are also covered by the EU’s Web Accessibility Directive (WAD).
Also see our suggested solution for mobile phone solutions (in Norwegian).
Test the app during development
It is important to keep universal design in mind from the start to ensure that the app complies with the requirements. You should test and user test the app several times during development and prior to completion.
The same applies when you complete error corrections and refinements of the app.
Use a screen reader for testing
Unlike websites, you usually do not have access to an app’s source code, unless you are responsible for its development. App code is normally compiled before it is published. Good quality coding is a prerequisite for ensuring that the app will function with screen readers and other assistive technology.
We recommend that you test the app with a screen reader to check navigation, reading order, and whether menus and content are read out aloud. If the app functions well with a screen reader this indicates that the code quality is appropriate.
You should test the app in relation to both iOS and Android.
- How to use iOS – Voice Over.
- How to use Android – Talk Back.
The Authority’s practices regarding apps
The Authority receives relatively few enquiries regarding the universal design of apps. We have tested apps in cases where the Authority has provided professional opinions on ICT to the Norwegian Anti-Discrimination Tribunal.
We provide such statements at the request of the Norwegian Anti-Discrimination Tribunal in connection with their consideration of discrimination complaints. One common theme in many cases is that the apps do not function for the visually impaired. One example of this is the complaint regarding Vipps (in Norwegian).
Upcoming regulations for apps – WAD and WCAG 2.1
WCAG 2.1 will become part of the Norwegian regulations through the EU’s Web Accessibility Directive (WAD), although no decision has been made about when this will be approved. The standard in WAD is EN 301 549, which in turn refers to WCAG 2.1
Some special characteristics of applications are not particularly well covered in WCAG 2.0. They are covered better in WCAG 2.1. A new version of the standard includes requirements that are more relevant for touch screens, gestures and preventing accidental content activation.
Link list for apps
- Legal notice: Applications are subject to universal design requirements for ICT (in Norwegian).
- Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile.
- Roadmap of Web Applications on Mobile.
- SmartJa – Simple tips for smartphone and tablet (in Norwegian).
- Norwegian Computing Center - Report on Best Practices for Accessible Mobile Apps.
- Google – Developing for Accessibility.
- Apple – Accessibility Programming Guide for iOS.