April 10, 2006
In this weeks show we get “down and dirty” with web accessibility, including a step-by-step tutorial into the WAI guidelines.
Get Paul Boag’s podcast Understanding accessibility guidelines, which gives Paul’s fairly good run-down of WCAG 1.0 checkpoints. Unfortunately there’s no transcript…
A few notes I made while listening to this:
| Time | Checkpoint | Paul’s take | Note |
|---|---|---|---|
| 14:42 | If you go on to the effort of being AA compliant, you might as well be AAA - because it’s not a huge step on. I suppose it’s a bit more fiddly… |
This depends on how you interpret checkpoint 11.3: provide information so that users may receive documents according to their preferences. and checkpoint 14.2: supplement text with graphic or auditory presentations where they will facilitate comprehension of the page.. If you’re strict about them, AAA can almost never be achieved, only strived towards. |
|
| 18:10 | Checkpoint 2.1: ensure that all information conveyed with color is also available without color. |
As an example, Paul suggests using bold and red, rather than just red, to denote required fields in a form. | This helps only if you’re trying to help a sighted user who is colour blind (or a user on a device that doesn’t support colours). However, a blind users won’t get much from the bold visual styling either. It’s best to make required form fields absolutely explicit by adding an actual bit of text in the field’s label, for instance. |
| 22:30 | Checkpoint 6.2: ensure that equivalents for dynamic content are updated when the dynamic content changes. |
You change the page title for a particular page…now, if you’ve used images for the page title, and you used image replacement…you don’t want the text to be the new title but the image to be the old one. |
True, but what possibly happens in more cases is the opposite: the image is changed (by a visual designer), but the alternative/replaced text isn’t…as rightly mentioned later on. |
| 23:25 | ALT tag |
A cheap shot, but it’s always worth reminding people: it’s an ALT attribute, not a tag. | |
| 24:30 | Checkpoint 7.1: until user agents allow users to control flickering, avoid causing the screen to flicker. |
Hard to interpret, what’s flashing…open to interpretation |
There are some general rules of thumb with regards to problematic flickering frequency:
The duration and size of the flashing area also plays a part (for this last point, as an extreme example: a single pixel that flashes will not have the same seizure-inducing effect as the entire screen flashing). |
| 28:24 | Checkpoint 9.1(provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape. |
Paul notes that he doesn’t really get this one. |
Client side image maps (which are really the ones most commonly used nowadays) can only have simple geometrical areas defined as hotspots (rectangles, circles, polygons). Server-side image maps, on the other hand, can have all sorts of shapes. When the user clicks on the server-side map, the X and Y coordinates of the click are sent to the server; here, you could have all sorts of processing to work out what was clicked…you could define any type of shape, even have a different destination for every single X and Y coordinate pair / pixel. Now, client-side image maps do not require a roundtrip to the server to work out what url the browser should load. Also, the regions defined in the client-side map can be accessed via the keyboard (tabbing through like normal links in most visual browsers), whereas server-side image maps (where the browser has no clue what, if any, areas of the image are hotspots) simply cannot be actived via the keyboard (unless you use a virtual pointer or similar). Hardly seen in the wild, but something very much related (and just as bad) are image inputs in forms, for instance the world map at geourl.org (if you’re using the X and Y coordinates, and not just taking advantage of the image input as a “stylish” alternative to a proper submit button). |
| 30:45 | Checkpoint 12.1: title each frame to facilitate frame identification and navigation. |
That’s so you can bookmark them and stuff like that… |
No, the checkpoint is not referring to the title of the document contained in the frame. It refers to the title attribute of the frame in the frameset definition. This way if a user with assistive technology comes across the framed site, they can get information about what each frame contains before they dive into it (e.g. a frame titled “navigation” and another one “content” (see the associated HTML technique for details). |
| 32:00 | Checkpoint 1.3: until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation. |
This is a slightly controversial one that most sites claiming full AA or AAA don’t do. Admittedly, the effort involved with creating a good audio description is quite high. | |
| 38:50 | Checkpoint 3.1: when an appropriate markup language exists, use markup rather than images to convey information. |
You can still be priority 2 compliant and use images for headings as long as you’re doing it with web standards again where you’re using an image replacement technique. |
Just to clarify that image replacement techniques are not web standards per se. I can still use an IMG element and follow web standards, and in many cases I have argued that this is still acceptable (provided that the contrast and size of the text used in the image is ok enough for most general situations). |
| 39:28 | Checkpoint 3.2: create documents that validate to published formal grammars. |
As already pointed out in the podcast comments, this has nothing to do with cognitive disabilities and bad grammar being hard to read. It’s about your markup validating (passing W3C HTML/CSS validators). It was fun to listen to the very elaborate rationale, though. | |
| 43:05 | Checkpoint 3.3: use style sheets to control layout and presentation. |
You cannot be priority 2 compliant if you’re doing table based design. |
As noted later, unfortunately checkpoint 5.3: do not use tables for layout unless the table makes sense when linearized. is the get-out clause for this one. This is one of those cases where WCAG 1.0 whussed out. |
| 44:03 | Checkpoint 3.4: use relative rather than absolute units in markup language attribute values and style sheet property values. |
Note the additional sentence in the technique though: If absolute units are used, validate that the rendered content is usable. Within reason, fixing a layout to a certain size may still be ok, if testing shows that it does not impede actual users. Taking it to the letter, this would preclude anything, even max-width. |
|
| 46:00 | It’s about making your content fit the window |
But that can be counter-productive. On large screens, it results in overly long and difficult to read one-liners, for instance. Not completely clear-cut in my opinion. If all else fails, offering alternative stylesheets can be the answer. | |
| 55:03 | Checkpoint 5.4: if a table is used for layout, do not use any structural markup for the purpose of visual formatting. |
Structural markup here refers to additional structural elements and attributes specific to data tables, beyond the most basic row and cell definitions. For instance, this would mean not using TH in a layout table only to achieve bold text. This also invalidates a common misguided practice of adding a summary of “layout table” to a layout table. | |
| 56:23 | Checkpoint 10.2: until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned. |
Make sure your label is next to your input |
Not just that it’s next to it, but that it’s in the correct order: for most label text, it should come before the input; for radio buttons and checkboxes, it should come after the input. Otherwise assistive technology such as screen readers trying to compensate for the fact that you didn’t use an explicit label will get confused and read the wrong text as the label for the input. |
| 57:08 | Checkpoint 12.4: associate labels explicitly with their controls. |
The difference between implicit and explicit labels: explicit labels use the FOR attribute to specify which form control they refer to, and don’t just rely on being next to (or wrapped around) it. | |
| 1:02:48 | Checkpoint 9.5: provide keyboard shortcuts to important links, form controls, and groups of form controls. |
They can use those keyboard shortcuts if they want to… |
The root of the problem is, though, that they can conflict with your browser, operating system or assistive technology controls. So users may not want to use them, but - while trying to access a particular function - they trigger them. Accesskeys can effectively hijack a user’s control; for instance, imagine defining an accesskey “F”…this would prevent an Internet Explorer user from jumping to the File menu. |
| 1:03:35 | Checkpoint 10.5: until user agents render adjacent links distinctly, include non-link, printable characters between adjacent links. |
Make sure there are spaces between links. |
No, not just spaces. This checkpoint refers to old browsers coupled with old screen readers which had a serious issue with links, even when they were separated by spaces. That’s why the checkpoint specifies that these separating characters need to be printable…simple space is not enough, and that’s why many people started using pipe characters, and so forth. However, this is a non-issue from a technical accessibility point of view, as any browsers and assistive technologies in use today should really recognise adjactent links, even in the extreme case where there’s absolutely nothing between them. Although from a usability point of view it’s still a valid point that you shouldn’t have links butt up against each other. |
| 1:03:57 | Checkpoint 11.3: provide information so that users may receive documents according to their preferences. |
Basically it’s saying: provide alternatives. |
Glossed over a fairly big kicker here: taken at face value, this means that your site needs to be fully multilingual and multimodal. What if a user has a preference for Mandarin Chinese? Simple graphics instead of text? Sound rather than visuals? This is one of those priority 3 checkpoints that seem impossible to fully implement, which makes sites claiming AAA not achievable if taken to the extreme. |
| 1:09:35 | Checkpoint 5.6: provide abbreviations for header labels. |
If you keep your header label short you can then explain them with a longer description. |
No, other way around: you can have long header labels, but then provide an abbreviated version which is read out so the user doesn’t have to hear the long header all the time as they travel through the table. The ABBR attribute of table headings works in exactly the opposite way of ABBR elements. See the explanation of the ABBR attribute in the HTML 4.01 specification for TH |