A collection of tips, guidance and practical suggestions in developing accessible websites
Collecting practical and useful web accessibility tips and guidance into bite-sized chunks. Best practices derived from working on popular and heavily trafficked websites. This site goes beyond the basics and dogma to focus on practical aspects and issues that affect people with disabilities.
Hi, I’m Mike Davies, and I am a Senior Web Developer for Yahoo!. I work in an exceptionally talented and highly skilled web development team based in London. The advice offered here has been used in our day-to-day work, so if it’s safe for use on Yahoo, these tips and guidance should be safe to use on your own sites.
My work as a technical lead developer (and accessibility consultant) was the basis of Legal & General’s concrete case study about the business benefits of web accessibility, and was presented at the launch of PAS 78 (Guide to commissioning accessible websites). The main point was that improving the accessibility of the site led to a 200% plus growth in L&G’s online business across all of it’s financial products.
You’ve got some real gems here (e.g. using the title attribute for form elements when appropriate). I like the idea of “keeping things simple” and trying to use logical markup and coding practices to avoid problems. Thanks for sharing these tips, they’re very helpful!
Thanks for the great resource. I’m wondering if you could do a post on in-place editing in an AJAX-y application.
We’re having lots of trouble coming to consensus in the office, especially around the issue of explicit actions tied to buttons.
I’ll give you the scenarios we’re debating ..
1 – In Place Edit with No Buttons
[ Editable Text ]
Save on “leave focus”, Cancel on ESC.
2 – In Place Edit with Buttons
[ Editable Text ] (Save) (Cancel)
No action on “leave focus”, only explicit Save and Cancel.
Both have shortfalls.
I agree with the previous commenter. There’s great stuff here. The only problem is there’s no link to your feed — nowhere. I had to go out of my way to type feed behind your domain, which worked, but ironically isn’t very accessible.
Also, you should turn on full posts in your feed. I and a growing majority find excerpts exceedingly annoying. Though, it does give definite kudos to you that I added your feed anyways.
Chris, thanks for your comments.
This blog, as with many WordPress blogs, uses autodiscovery to make the feeds known to a browser. Any modern browser will highlight the feed, typically an RSS icon in the address bar. This is the standard way of exposing feeds for syndication in feed readers. For the record, the autodiscovery feed links to the URL: http://accessibilitytips.com/feed/atom/
I’m uncomfortable with an on-page link to the RSS feed because it creates an obstacle to people navigating the site. Should someone follow the link they are greeted with what is seemingly a garbled document, and the only way out is back. This is just a bad user experience. Autodiscovery is a mechanism for flagging the availability of a feed without this usability barrier.
Also, full posts are turned on in this blog. If you understand RSS or Atom you can check for yourself that the full content of posts is in the feed. Unfortunately WordPress’ default is to supply both the summary and the full content of posts when this option is selected, and many feed-displayers take the summary even when the full content is available. I’ve rectified that in this blog by removing the summary elements from the Atom feed, since that should force feed-parsers to use the full-content element instead.
Thank you for subscribing, I hope I can earn the right to remain a subscription in your feed reader.
I can add in-place editing to my todo list for this blog.
A quick answer to your query is this:
The key problem with in-place editing is being able to trigger an event that allows an edit to take place, and also to trigger an event to save/process the completed edit.
The simplest way would be to use form buttons to edit and save a piece of text. Since that makes the actual functionality perceivable and operable.
Trying to do this functionality without buttons means that it is critical that the trigger to switch into edit mode must be focusable, i.e. a keyboard user needs to be able to tab to some focusable element that they can then activate to start editing a piece of text.
Without using buttons, I suppose you could make each text focusable by supplying the container with a tabindex of a value that is focusable. That solves the operability part of accessibility, but perhaps not the perceivability (but that could be solved by an explanatory sentence before the editable text explaining how to edit the text).
Exiting the edit mode could simply just be a case of the text field losing focus. But think about how the user can ‘cancel’ an edit.
The buttons are a simpler approach, but there are tradeoffs in the default mouse-capable interaction design.
Hope that helps,