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.
Mark Root-Wiley explains why navigation menus that appear on click rather than hover are better.
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.
Jeremy Keith takes us through his thought process regarding the choice of link or
button when planning accessible interactive disclosure elements.
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.
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.
Strong agree with these sentiments regarding accessibility expressed by Max Böck and Andrey Okonetchnikov on Twitter.
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.
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.
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.