Shawn at the W3C wants feedback on the ARIA working draft, particularly "feedback on host language embedding, that is, how ARIA is implemented in HTML, XHTML, SVG, and other host languages." If you don't chime in now, don't bitch later.
This online course from Sara looks superb!
I know how overwhelming and even frustrating accessibility may feel at first. But I promise you, accessibility isn’t always as hard as it seems (especially if you know where and when to start!). And my goal with this course is to make it friendlier and more approachable.
Best of all, there’s $100 off if you sign up now—that’s a 25% saving.
The slides from Hidde’s presentation at Paris Web—a great overview of using and misusing ARIA.
I’ve done this quite a bit: using ARIA attributes as “hooks” for styling and behaviour. It’s a way of thinking of accessibility as the baseline to build upon rather than something that can sprinkled on top later.
On the surface this is about the pros and cons of minting a new HTML search element to replace div role="search" but there’s a deeper point which is that, while ARIA exists to the plug the gaps in HTML, the long-term goal is to have no gaps.
ARIA is not meant to replace HTML. If anything, the need to use ARIA as ‘polyfill’ for HTML semantics could be considered as a sign and a constant reminder of the fact that HTML falls short on some semantics that benefit users of assistive technologies.
A good tutorial on making password fields accessible when you’ve got the option to show and hide the input.
It’s not just about finding the issues—it’s about finding the issues at the right time.
Do websites need to sound the same in every screen reader?
Stop me before I use ARIA incorrectly again.
Tweaking some ARIA attributes.
The latest installment in the long tradition of calling for this pseudo-element.