Accessible Christmas Alphabet
C is for Client side scripting, progressive you’ll agree.
H is for page Headings that will help both you and me.
R is for Relative text — from pixels we’ll abstain.
I is for Identifying language or text that’s not mundane.
S is for Style sheets because they keep your file size small.
T is for Tabindex — don’t make it a bad call.
M is for the Markup — make sure a list’s a list.
A is for Alternative when images are missed.
S is for Skip links so TAB users never fret.
Be good and users will love your Accessible Christmas Alphabet!
Client Side Scripting
You have some real neat pieces of JavaScript that you want to use in a design but, mindful that not all of your visitors will be browsing with JavaScript enabled, you carefully add <noscript> sections to support non-JavaScript browsers. However, as Tommy Olsson pointed out, this approach (which is known as “Graceful Degradation”) has some drawbacks. Instead, rather than starting with a JavaScript enabled design and working backwards, begin with the basic version and then add your JavaScripts as enhancements for those who can access them.
Form validation is a good example. Some forms use JavaScript to report submission errors but unless this is backed up with solid server-side error reporting, we risk confusing non-JavaScript users who will have no idea why their completed form isn’t being accepted. However, if we add any client-side scripting on top of our basic server-side validation, we have the opportunity to provide quicker feedback to most users, reduce the number of server requests but keep all users informed. Tommy offers an example of this approach in his original article.
Headings
Good use of structured headings is essential for both imparting information quickly and breaking down content into manageable chunks. Some user groups rely upon a logical and hierarchical header structure to convey a mental model of a page — especially the visually impaired. Others groups have a low “information threshold” and need headers to break down the page content into smaller sections that they can absorb the content more easily. Finally, some screen reading software can extract all of the header text on a page and present them as a list to the user. JAWS users can also “jump” from one heading to another using a keyboard shortcut. Both of these options allow visually-impaired users to “scan” pages for relevant information in the same way that sighted users glance through a page before deciding whether to read a given section more closely.
Skipping headers — or in some cases, not using heading elements at all — can create significant problems for many users whilst using headings properly can support their reading. Headings are also useful for the Net’s most prolific blind user — Google — and this is one user we all want to please!
Relative Font Sizes
One of the most common and frustrating issues that many disabled users face on a daily basis is fixed size text. And by “fixed size text”, I mean text whose size has been set using anything other than %, em or ex.
Yes, I know pixels are a relative font size but, at the end of the day, what users need is the ability to alter text size within their web browser. What they don’t need is a text sizing that forces them to adjust make adjustments by resetting their screen resolution. For most users, that’s way too fiddly. As for Internet Explorer 7, it doesn’t resize text specified in pixels. Instead, the user has to zoom the entire page (including images) — sometimes resulting in a badly broken page because of existing bugs within Internet Explorer’s Zoom feature.
So, bottom line, if a user can’t resize just the text within their web browser, you’ve created a problem.
Identify The Language Of Your Content
Not everyone can pronounce, interpret or understand abbreviated or foreign text. This is especially true when users rely on speech synthesizers and braille devices to render page content. If you markup up any languages changes, software may be able to automatically switch to the new language, making the page more accessible to multilingual users.
Examples:
- Within the
HEADsection of an English language page: <html xmlns="http://www.w3.org/1999/xhtml" lang="en">- French on an English language page:
<span lang="fr">objet d'art</span>- Abbreviations:
<abbr title="Small to Medium sized Enterprise">SME</abbr>
If your page content is important enough to be published surely, it makes sense to ensure that it is as understandable as possible to as many visitors as possible? There’s also another search engine benefit here. Language markup allows search engines to find key words — including foreign phrases and abbreviations — and identify documents in the appropriate language.
Style Sheets
We’ll keep this short and sweet. Use them! Cascading Style Sheets (CSS) allow designers to separate page content from its presentation which, in turn, offers the following benefits:
- The ability to (re)define the look of an entire site site in a handful of files irrespective of how many pages the site contains.
- Options to offer different layouts for different purposes (screen, print, handheld, projection etc.)
- Reduced page download and rendering times — the CSS for a site is downloaded once no matter how many pages are viewed, so all subsequent downloads require only the basic page and the browser can immediately begin the rendering process because there is little, if any, presentational markup in the page.
- Decreased maintenance time — pages that do not contain presentational information can be a lot easier to re-code.
- Increased accessibility — users can opt to turn off CSS or use their own local style sheet to improve readability.
You know it makes sense…
Tabindex
Tabindexing allows you, the designer, to specify the order in which links or controls receive focus on a page when using the TAB key to move around. The Web Content Accessibility Guidelines 1.0 state:
Create a logical tab order through links, form controls, and objects.
Checkpoint 9.4
But before you get carried away and start tabindexing everything in sight, do note that the Guidelines suggest that you “specify tab order via the tabindex attribute or ensure a logical page design”. The keyword here is “or”. If the tab order on your page already logical and intuitive, you do not have do anything more! If you do plan to incorporate tabindex, stop and ask yourself why.
One common use of tabindexing on pages that contain forms gives preference to the form controls and leaves the site navigation and/or page links unindexed. When the user hits the TAB key — expecting to jump to the first link on the page — he may actually end up on the form and be forced to tab through the whole thing to get back to the navigation links which, visually, may be higher up the page. The end result (especially if there is a lack of visual highlighting on links with current focus) is often complete user disorientation and exasperation — simply because the designer assumed that every visitor to a form page would want to complete the form. To put it bluntly, that’s a stupid assumption to make.
I’ve also come across English language pages (natural tab order: left-to-right, top-to-bottom) where the tab order of some links has been changed to right-to-left. I have no doubt that the reverse exists on some Arabic or Chinese pages. Why? I have no idea other than perhaps it’s considered “funky.” Which is about right as it may well induce a case of “user funk”.
So, the rules boil down to:
- Don’t use tabindex unless you have a very good reason to do so.
- Don’t assume that you can predict where a user will want to go first on a given page.
- Don’t interfere with a languages natural tab/reading order.
Markup
Markup can be defined as data which is added to the content of a document to describes the text it contains.
When marking up new content, your first thought should be “What kind of content is this?” and not “How should it look?” If you’re looking at a list, use list markup (<li>) — not line breaks (<br />). If you have a verse from a song or a few lines from the Chairman’s annual speech, use <blockquote>. You can style it later as long as you don’t rely on visual styling alone to identify quoted material. And never, ever, use markup for purely presentational effects — which means no using <blockquote> to indent text unless this really is a quotation.
Markup is the foundation upon which all pages are built, so use good semantic markup to give your pages a really solid foundation.
The Alt Attribute
The “alt attribute” simply contains text which can be used if the image is not be available. Unfortunately, this sometimes leads to confusion as to what alt text should be used and when.
First of all, we need to be clear on one thing — all embedded images must be accompanied by an alt attribute. Omit the attribute and you invalidate your entire page. Once that concept is understood, some people then seem to struggle with deciding how much text to use or even if you should use any text at all. Mike Cherim’s “The Alt and Accessibility” article defines 4 types of embedded image:
- Decorative
- Relative
- Descriptive
- Definitive
I’m not going to replicate Mike’s article here but I thought I could offer a little exercise that I’ve found very useful when trying to decide which of the above categories a given image fits into.
The Exercise
Imagine you are trying to read a web page over the telephone to a friend. As you hit each image, what would you say? Would you:
- Not bother describing the image at all?
- Use no more than 2 words that encapsulate the concept that the image portrays?
- Describe the image using a short phrase?
- Spend some time describing the image in detail?
Congratulations! You’ve not only just categorised your image but you’ve almost certainly created the right alt text for it at the same time.
Skip Links
Skip links are a boon for any keyboard navigator. They can turn an almost unusable page of links into something that a keyboard user can navigate without expending herculean effort.
“Ah but…” I hear you say “Doesn’t screen reader software have its own keyboard navigation shortcuts?”
Why, yes it does… which brings us to the second, and less fully understood, point. Not all keyboard navigators have a sight problem. In fact, I’d go as far as to say that the total number of sighted keyboard navigators may equal, or even exceed, the number of visually impaired screen reader users. And this is why skip links need to be visible.
This does not mean that you have to have “Skip to content” links permanently cluttering up your design. In fact this site uses an approach which brings skip links into view only when a visitor TABs into the page. The average mouse user never sees these links but the sighted keyboard navigator has immediate access to them on every page. The fact that the links disappear when they lose focus is of no consequence either. As every keyboard navigator knows, the only really useful link is the one with current focus. So all our keyboard using visitors need to do is either reverse back up the page or cycle the page by going to the bottom and pressing TAB a couple of times.
And whilst you’re looking at links, add some strong background color changes to your a:focus and a:active link CSS declarations. The net effect will be that keyboard navigators will be able to see exactly where they are within any given page. Put these two accessibility enhancements together and you have a really useful Christmas present for all of your sighted keyboard using visitors.
Now wouldn’t that be a nice note to end the year on?
Mike Cherim responds:
Posted: December 22nd, 2007 at 8:52 pm →
Easy as A-B-C… Merry Christmas everyone!
Deborah responds:
Posted: December 24th, 2007 at 8:40 am →
Lovely, and what a wonderful present to share with all of us! Now, the only decision is what holiday music should be sung with it?
David Zemens responds:
Posted: December 24th, 2007 at 7:40 pm →
Great article and a nice, end of year reminder about accessible web practices. In fact, I had not even noticed the rhyming nature of the post until Deborah pointed it out. Very cool.