Your weekly frequent11y newsletter, brought to you by @ChrisBAshton:
Face-off: Should kit colours be catered to colour-blind fans?
Anyone who’s ever played FIFA on a game console will at some point have ended up playing a game where both sides have really similar looking kits. It becomes difficult to know who you can pass to, and makes the game less enjoyable.
This is an issue faced by the large portion of sports viewers who are colour blind, and consequently, the 2027 Rugby World Cup will be the first that bans red-green kit clashes.
This article from RugbyWorld.com shares an opinion-piece from two enthusiasts. The first is in favour of the move, for obvious reasons. The latter is against it, favouring the idea of a ‘home kit’ and an ‘alternative white kit’, which would solve the problem in a different way. He argues that “turning out in the colour of your nation matters”.
I think the announcement is a positive move for accessibility, but it’s interesting to think about the different ways the issue can be tackled.
Accessible front-end components: claims vs reality
Hidde de Vries shares his tips for finding accessible components, warning that many components that claim to be “accessible” actually aren’t. Hidde’s checklist:
- How did they test? A component’s website should ideally explain how a component was tested, e.g. perhaps only automated tests have been run and you should do some further testing before choosing it. Try to find specifics around exactly what version of WCAG they claim to be valid against, for example.
- Who did they test with? Accessibility isn’t just about technology, it’s about making sure a pattern works for people with disabilities. Did the developers specifically include people with disabilities, in their testing?
- Are they open about the pros and cons of their approach? It’s a good sign if the developer is open about this, as many components aren’t one-size-fits-all.
- Who created them? Hidde puts extra trust in components developed by organisations that work in accessibility or work for the public good.
- Look at GitHub issues – their presence could be a warning sign.
- Find out about commitment – are they proactive or reactive in their component’s development?
Brief Note on Buttons, Enter, and Space
An interesting article by Adrian Roselli, sharing something I didn’t know:
A native
<button>fires on key down when that key is Enter. If you hold down the Enter key, it continues to fire for as long you hold Enter (or something crashes).A native
<button>fires on key up when that key is Space. If you do not release the Space, and also press Tab to move away from the control, the control will not fire.These can blow up once a screen reader is in play. If you run Narrator/Edge, pressing Space is the same as pressing Enter, but holding either down does not repeatedly fire the event. NVDA/Firefox and JAWS/Chrome treat Space as Enter — fires on key down and holding it down continues to fire. The Windows screen readers all intercept the event, so you cannot listen for which key was pressed in your page. VoiceOver/Safari/macOS behaves as if VO was not running, and (in my script) the keyboard events are captured.
…and that’s pretty much the whole article! There’s also an interactive example so you can try it out for yourself. The TLDR is to be careful when trying to re-implement native browser behaviour in your custom components, and consider the nuance of the different keys, to support your powerusers.
Did you know that you can subscribe to dai11y, week11y, fortnight11y or month11y updates! Every newsletter gets the same content; it is your choice to have short, regular emails or longer, less frequent ones. Curated with ♥ by developer @ChrisBAshton.
