EN 301 549 Clause 5 - Generic Requirements
Published
Generic Requirements
This section coveres:
- Visual access
- Auditory access
- Physical access
- Speech input
- Motor control
- Cognitive processing
- Privacy
5.1 Closed Functionality
Clause 5.1 talks about what Closed functionality is and how an ICT with closed functionality should ensure accessibility. The clause states that an ICT with closed functionality should not require that users attach assistive technologies to use the system. Personal headsets and personal induction loops are not considered assistive technology for the purpose of this clause.
I especially liked:
- The details in 5.1.3 about non-visual access, the system should not only speak but also allow control, protect privacy, and even manage volume accessibly.
- The inclusion of privacy as a non-negotiable. WCAG doesn't really say much about it, but EN 301 549 clearly ensures that accessibility doesn't cost people their privacy.
- 5.1.7 Access without speech: because yes, making a non-verbal person speak to activate a non-speech alternative is just... straight to jail behavior.
One important thing to keep in mind is that if you have an ICT with closed functionality you need to consider the requirement in other clauses (5.2 - 13) in the standard.
5.2 Activation of Accessibility Features
This section is the you can't put the ramp inside the locked building
.
In short it's saying: Don't require people to use what they can't use in order to activate what they
need.
and while that sounds obvious, in practice, Some apps require blind people to go through a visual
settings to toggle voice guidance
It's could be a real problem. I mean, a websites that requires you to log in to change your accessibility settings, OR a system that requires you to use a mouse to turn on keyboard navigation should not be considered accessible.
5.3 Biometrics
This one is especially relevant now that Face ID or fingerprint-only security are common.
In summary, it's not saying "Don't use biometrics", it's saying give people choices. If someone can't provide a fingerprint, give them a PIN. If someone can't speak clearly for voice ID, let them scan a card.
5.4 Preservation of Accessibility Information During Conversion
This part is about respecting the integrity of accessible content.
It says that if you convert a document, you have to make sure that the accessibility features stay intact in the converted format.
Accessibility info can be fragile. When you convert files, it's easy to lose alt text, headings, captions, and this clause ensures that this doesn't happen.
5.5 Operable Parts
This clause had two parts:
- making sure things don't require grasping, pinching, or wrist-twisting
- making sure people can find controls by touch.
It made me realize just how many modern devices fail this. From flat touchscreen ovens to slippery volume buttons. This clause makes sure that people with motor impairments can use the controls without needing to do things that are physically impossible for them.
5.6 Locking or Toggle Controls
This part addresses both tactile/auditory and visual states, It ensures that an ICT provides at least one mode of operation where the status of the control can be determined either through touch or sound without operating the control.
An example of a locking or toggle control is the "Caps Lock" key. because even something as “small” as Caps Lock can cause chaos if you can't tell what it's state is.
5.7 Key Repeat
Key repeat is about making sure that if you hold down a key, it doesn't just keep repeating endlessly. This is important for people with motor impairments who might not be able to release a key quickly.
It's refreshing to see a standard that slows things down instead of expecting users to keep up with tech. It recognizes that some users:
- Hold keys too long
- Can't lift their fingers quickly
- Might hit the key accidentally
It also says that if you have a key repeat feature, it should be adjustable. So if someone needs more time to release a key, they can set it up that way.
5.8 Double-Strike Key Acceptance
This part focuses on accessibility for people with tremors, or inconsistent movement. It ensures that users can adjust how long a system waits before accepting a repeated keystroke. The recommended time is at least 0.5 seconds.
5.9 Simultaneous User Actions
Actions that require two hands or multi-touch gestures, must have a one-step, one-hand, or one-finger alternative.
Having to use both hands to open the lid of a laptop, having to press two or more keys at the same time or having to touch a surface with more than one finger (for example: pinch to zoom) are examples of simultaneous user actions.
Up next: Clause 6, ICT with two-way voice communication.
Check-In
I've not been posting as often as I want to, life's been doing its thing 😅. But I've still been reading and studying, even if it's just 30 minutes a day. Writing it all out takes a different kind of focus though.
Once things settle down a bit, I'll get back to writing more regularly. For now, slow progress is still progress.