I think these are great habit-forming ideas for any web designer or developer: a day without using your mouse; a day with your display set to grayscale; a day spent using a different web browser; a day with your internet connection throttled. I’m going to try these!
Six steps that everyone can do to catch accessibility gotchas:
- Check image descriptions
- Disable all styles
- Validate HTML
- Check the document outline
- Grayscale mode
- Use the keyboard
In some situations, a date picker is overkill:
I have relied on plain text inputs as date fields with custom validation for the site, typically using the same logic on the client and the server. For known dates — birthdays, holidays, anniversaries, etc — it has tested well.
A deep dive into the :focus pseudo-class and why it’s important.
Paul walks us through the process of making some incremental accessibility improvements to this year’s 24 Ways.
Creating something new will always attract attention and admiration, but there’s an under-celebrated nobility in improving what already exists. While not all changes may be visual, they can have just as much impact.
If you enjoyed reading Marcin’s serendipitous story on Twitter, here are the pictures to accompany it.
Ire rounds up a bunch of tools you can use to test accessibility, from dev tools to Tenon.
Choosing the right input type for your form field.
Jason breaks down the myths of inputs being tied to device form factors. Instead, given the inherent uncertainty around input, the only sensible approach is progressive enhancement.
Now is the time to experiment with new forms of web input. The key is to build a baseline input experience that works everywhere and then progressively enhance to take advantage of new capabilities of devices if they are available.
A useful primer on which combinations of attributes and values work best for which form fields: type, autocomplete, autocorrect, and autocapitalize.
It really isn’t hard to get the basics of accessibility right on the web …and yet those basics are often neglected.
Here’s a handy shortlist to run through, HIKE:
- H stands for headings and semantic markup.
- I stands for images and labels.
- K stands for keyboard navigation.
- E asks for you to ACT with a little extra love for custom components and more.
(ACT = ARIA, Colour Contrast, Text Size)
Jessica’s handy guide to writing the right quotes and accents on a Mac keyboard.
A great piece by Jason analysing the ever-blurring lines between device classes.
Mind you, there is one question he doesn’t answer which would help clear up his framing of the situation. That question is:
What’s a web app?
Josh takes an-depth look at the navigation design implications of touch/keyboard hybrid devices, coming to a similar conclusion as Luke and Jason:
Unfortunately, the top-of-screen navigation and menus of traditional desktop layouts are outright hostile to hybrid ergonomics. Tried-and-true desktop conventions have to change to make room for fingers and thumbs.
Want to test for a hybrid device? Tough luck. Instead, argues Josh, the best you can do is assume that any device visiting your site could be touch-enabled.
Because everything goes better with keyboard cat.
When localisation attacks. This is like a more morbid Douglas Adams vignette.
I would kill to get hold of this Steampunk Mac mini, flat panel monitor and brass keyboard.
Handy Firefox keyboard shortcuts, courtesy of Derek.