Tagged “accessibility”
Shifting left: how introducing accessibility earlier helps the BBC’s design system (by Sophie Beaumont)
Absolute gold here regarding accessibility, bloated components, and purpose versus appearance.
It’s easy for a component to become bloated and its purpose increasingly ambiguous.
In Praise of the Unambiguous Click Menu (on CSS-Tricks)
Mark Root-Wiley explains why navigation menus that appear on click rather than hover are better.
Use Mac Zoom to show the text a screen reader gets
I picked up a good accessibility testing tip from my work colleague Max today.
On a Mac, if you open System > Accessibility > Zoom, you can enable “hover text”. This allows you to hold down command (cmd) and then whatever is under the mouse will be shown. This shows the same text that a screen reader sees so it’s good for checking if bits of the page respond to a screen reader.
Accessible interactions (on Adactio)
Jeremy Keith takes us through his thought process regarding the choice of link or button when planning accessible interactive disclosure elements.
Progressively enhanced JavaScript In Real Life
Over the last couple of days I’ve witnessed a good example of progressive enhancement “In Real Life”. And I think it’s good to log and share these validations of web development best practices when they happen so that their benefits can be seen as real rather than theoretical.
Assistiv Labs
A tool for testing how accessible your experience is on various assistive technologies – perhaps “like BrowserStack but for screen readers”?
Assistiv Labs remotely connects you to real assistive technologies, like NVDA, VoiceOver, and TalkBack, using any modern web browser.
A11y is not “extra effort for people with disabilities”
Strong agree with these sentiments regarding accessibility expressed by Max Böck and Andrey Okonetchnikov on Twitter.
From Andrey:
If you’re building UI, it’s your responsibility to make it work for everyone. Clients often tell me “we don’t care about accessibility” but in reality they do want keyboard support at the very least. So I just build my UI in a way it works without discussing it. It’s my job.
How-to: Create accessible forms - The A11Y Project
Here are five bite-sized and practical chunks of advice for creating accessible forms.
- Always label your inputs.
- Highlight input elements on focus.
- Break long forms into smaller sections/pages.
- Provide error messages (rather than just colour-based indicators)
- Avoid horizontal layout forms unless necessary.
When there is no content between headings
Hidde de Vries explains why an HTML heading should never be immediately followed by another.
When you use a heading element, you set the expectation of content.
See all tags.