Missing Success Criteria for software in EN 301549
, by Emanuel Helms
Bypass Blocks and Consistent Navigation are two Success Criteria which you will be looking for in vain in Chapter 11 Software of the European Norm EN 301 549. This is the chapter that provides the technical basis for testing mobile apps. Is this an omission that should be corrected?
As far as accessibility requirements are concerned, the EU Web Directive refers to applicable standards and thus to the European standard EN 301 549 Version 2.1.2 (PDF). This standard was published at the end of August 2018 by the European Telecommunications Standards Institute (ETSI). In Chapter 11, it describes criteria for accessible software (i.e. non-web applications). This chapter is essentially based on the Success Criteria of the Web Content Accessibility Guidelines (WCAG) 2.1.
As the name suggests, WCAG's focus is on Success Criteria for web content - it is therefore not fully applicable to software. Chapter 11 of EN 301 549 therefore does not include all Success Criteria of WCAG 2.1.
However, users of assistive technology and accessibility experts may well put a question mark on the decision to remove some of the Success Criteria from the software part of the EN. In this article, I will cover two missing Success Criteria, 2.4.1 "Bypass Blocks " and 3.2.3 "Consistent Navigation", which in my opinion should have been retained as a requirement for software.
Success Criterion 2.4.1 "Bypass Blocks"
The purpose of this WCAG Success Criterion is to ensure that groups of content on websites (such as navigation areas) can be skipped, thus enabling quicker access to the information or functionality users are looking for. By correctly marking up these groups or providing mechanisms for skipping, users can jump directly to the main area of the web page – they do not have to fight their way through repetitive information and functions that are of no interest to him.
Why this success criterion which is enormously important for efficient use should not be applicable to software is not explained in the standard. The corresponding criterion number simply remains empty in the software chapter 11 of the EN.
Usual keyboard shortcuts for skipping
With more complex programs and apps, it is very common for keyboard users to use shortcuts for jumping back and forth between different areas - and for users of assistive technology, this is almost obligatory. Microsoft recommends some keyboard shortcuts in their Guidelines for Keyboard User Interface Design, and Apple also describes them in the Keyboard - User Interaction section of their Human Interface Guidelines. The best known example might be the F6 key (under MacOS applied together with the Ctrl key) for changing the system cursor to the next panel in the current application window.
These guidelines have been actively implemented by manufacturers of production software for years and in some cases describe a quasi-standard that is decades old. An example of typical use is the e-mail list in a mail program, where the F6 key can be used to jump from the list to the document area with the corresponding mail text. The situation is similar in File Explorer, where the same key can be used to switch directly from the tree view in the left area to the file list in the right area.
Skipping between blocks is critically important
These examples only scratch the surface. More complex applications such as Word and Excel, or development environments with their various toolbars, can hardly be used professionally with the keyboard without an appropriate shortcut. The requirement may seem trivial, but it saves a lot of time for experienced users and for users of assistive technologies in their daily work. And saving time is a very important aspect here, since in conjunction with well-programmed software, it enables people with disabilities to partially compensate for the additional time they many need due to their disability.
Applicability to mobile apps
The same applies to mobile apps which are becoming more function-rich and begin to blur the boundaries between mobile and stationary systems. Used with a physical keyboard, mobile apps offer similar functions to navigate the different areas of a software. Built-in assistive technologies such as VoiceOver (Apple) or TalkBack (Google) offer users a lot of functionality.
In my opinion, the ability to skip between areas in software has become an industry standard and would have hardly given software developers a major headache. Instead, the inclusion of “Bypass Blocks” in Chapter 11 of the EN would simply underpin a reasonable and easily achievable quality standard, mandating that developers follow already existing industry best practice.
Success Criterion 3.2.3 "Consistent Navigation"
The Success Criterion 3.2.3 “Consistent Navigation" requires developers to implement a consistent navigational structure on all pages of a website so that the user can easily find his or her way around and focus on the essentials. Therefore, the navigation area should always be kept in the same place and behave in the same way across pages -- essentially, ‘playing nice’ with user expectations.
Consistency helps all users
This Success Criterion is undoubtedly useful for all users, regardless of whether or not they use assistive technology. It is therefore difficult to understand that it did not make it into Chapter 11. The explanatory texts of WCAG 2.1 regarding Consistent Navigation could be taken over almost one-to-one for software.
If software takes this criterion into account, users increase their efficiency because they do not have to work out and learn different navigation structures of the individual views. Consistency eases users’ cognitive load. Once a consistent structure is understood, users can predict the structure in other navigation areas.
Consistent navigation supports learnability
Consistent navigation makes it easier for all users to familiarize themselves with new software and requires fewer cognitive skills for trivial tasks such as finding a menu item. People with disabilities benefit more than others from a consistent navigation. For example, when content is enlarged by screen magnification software so that only a small section is visible at any time, a consistent position means that users does not have to go on a hunt to find navigation areas. Visually impaired users can quickly lose orientation on the screen during this to-and-fro movement and must first recover and re-orient in order to continue their work.
The team that decided to cut out these two Success Criteria when porting WCAG to software certainly had their reasons. The transposition seems to have taken the WCAG2ICT document as a starting point. It would be useful if the arguments for the decision could be publicly scrutinised. We hope that the two Success Criteria that I have covered (and may be others, such as 3.2.4 Consistent Identification) may still find their way into a future version of the EN 301 549 standard.