ATAG assessment of WordPress

by Joe Clark

This document assesses WordPress 2.01 alpha against the Authoring Tool Accessibility Guidelines 1.0 (ATAG, pronounced “aytag”). You may add this document to the WordPress support wiki and use it in the normal fashion of a wiki, for collaborative editing.

I didn’t link to every single guideline and technique in the documents, as that would have doubled the time spent. They are, however, locatable.

Guideline 1. Support accessible authoring practices

  1. 1.1 Ensure that the author can produce accessible content in the markup language(s) supported by the tool.

    Partial pass.

    Techniques

    • Ensure the tool supports all the structural features of the supported languages.

    If by “support” you mean there’s a button on the toolbar for it, no. (All you’ve got there are b, i, a, blockquote, del, ins, img, ul, ol, li, and code.) If by “support” you mean the next criterion –

    • Allow the author to directly edit the source markup (so knowledgeable authors can ensure accessible content).

    – then yes. I’d give this a partial pass. It’s a clean fail for people who only use the toolbar but a pass for those who write their own HTML. (But those people only debatably need a blogging tool.)

    • When an extended (superset) or simplified (subset) markup language is supported, ensure that the accessibility features in the base language are still available.

    WordPress outputs XHTML 1.0 Transitional by default. You don’t get another option out of the box, though obviously it’s hackable to produce Strict or, if you want to go totally nuts, HTML. Not applicable.

    • Allow the addition of equivalent alternatives for all supported image formats that allow text content, including PNG, SVG, WebCGM, JPEG, and GIF.

    Prompts you for alt text automatically. Pass for that interpretation. WordPress does not edit PNG or SVG or whatever else, so that’s inapplicable.

    • Enable the author to produce metadata that can be used to construct an accessible version of the output. For example, when producing image formats that do not allow the inclusion of alternative information within them, use Dublin Core metadata to incorporate description, title information, or “foaf” metadata to identify people depicted in images.

    I don’t think this comes up in real-world blogging (when do you use “image formats that do not allow the inclusion of alternative information”?), so not applicable. You can use foaf only if you write out your own HTML or use a plug-in.

    • Notify the author, if a given output format is not accessible (so they can decide to use a different format).

    WordPress doesn’t output inaccessible formats per se; it isn’t an editor for PNG/SVG/PDF or whatever else. Not applicable.

  2. 1.2 Ensure that the tool preserves all accessibility information during authoring, transformations, and conversions.

    It doesn’t throw things away, but early versions had a hard time with certain unusual elements like caption, adding spurious linebreaks that destroyed validation. Pass for current version.

    Techniques

    • This checkpoint covers systems that digest documents and reconstitute them in standardized formats.

    Like WordPress.

    • Ensure that the tool preserves all the elements and attributes defined in the relevant specification(s) even if it is unable to render them in a publishing view or preview mode.

    Pass.

    • Allow the author to decide whether or not to preserve unrecognized markup (since it might be related to accessibility).
    • Consider explaining automatic changes made by the tool to the author.

    I don’t know of any, except for the option to “automatically correct invalidly-nested XHTML automatically” (Dashboard → Options → Writing). If you select that, then the tool has explained it to you. Both checkpoints not applicable, I suppose, since the intent here is to cover actions that the tool takes without your initial approval.

    • Allow authors to edit document conversion templates to specify the way presentation conventions should be converted into structural markup.

    Pass.

    • Ensure that changes to a document’s graphical layout do not reduce readability when rendered serially. For example, confirm the linearized reading order with the author.

    Irrelevant in the modern world; WordPress doesn’t use tables for layout, and CSS layouts are too complex to be reduced to an issue of linear reading. Not applicable.

    Some examples of conversion best practice include:

    • Avoid transforming text into images. Use style sheets for presentation control, or use an XML application such as Scalable Vector Graphics that keeps the text as text. If this is not possible, ensure that the text is available as equivalent text for the image.

    Not applicable.

    • When importing images with associated descriptions into a markup document, make the descriptions available through appropriate markup.

    I suppose this means longdesc. Fail.

    • When transforming a table to a list or list of lists, ensure that table headings are transformed into headings and that summary or caption information is retained as rendered content.

    Not applicable. WordPress doesn’t do that.

    • When converting linked elements (i.e. footnotes, endnotes, call-outs, annotations, references, etc.) provide them as inline content or maintain two-way linking.

    From what would you be converting such elements in a blogging tool? Not applicable.

    • When converting from an unstructured word-processor format to markup, ensure that headings and list items are transformed into appropriate structural markup (appropriate level of heading or type of list, etc.).

    Fail. If you copy and paste text, you don’t get semantically-correct headings automatically.

    • When generating a natural language translation of text, produce the simplest and clearest possible use of the new language.

    Not applicable and, in fact, misguided, pointless, condescending, controlling, and intrusive.

  3. 1.3 Ensure that when the tool automatically generates markup it conforms to the W3C’s Web Content Accessibility Guidelines 1.0.

    On its face, a pass. WordPress uses valid XHTML by default. If you want to get picky, then suddenly we’re talking about semantics and not validation, a concept with no real legs at the time ATAG was written.

    Also:

    1.4 Ensure that templates provided by the tool conform to the Web Content Accessibility Guidelines 1.0.

    I view these as almost equivalent given that WordPress is all about templates. Templates generate content.

    For both the above, WordPress flunks the following specific techniques when using the toolbar. If you’re writing your own HTML, it’s your own problem.

    All the rest either WordPress passes or are irrelevant or superseded by better practices. The failures listed above may be out of scope for a blogging tool.

Guideline 2. Generate standard markup

  1. 2.1 Use the latest versions of W3C Recommendations when they are available and appropriate for a task.

    Pass. XHTML is the current version of ()HTML.

    Techniques

    • When creating documents or markup languages, make full use of W3C Recommendations.... For example, use MathML for mathematical Web content and XHTML, MathML, and DOM scripting to implement dynamic-interactive spreadsheets.

    Not applicable.

    • In some cases a W3C Recommendation–formatted version may be offered in addition to a proprietary format. Tools that dynamically generate Web content may use HTTP content negotiation to facilitate this.

    Not applicable. Also quite incomprehensible.

    • Do not publish Web content in markup languages that do not allow for equivalent alternative information to be included for media-specific presentations (such as images or video, sound, etc.).

    Not applicable.

    • Although markup languages and formats that become W3C Recommendations after an authoring tool’s development cycle permit input are not considered “available” in time, modular design of tools provides for new markup languages and formats to be supported late in the development cycle or even after deployment.

    This isn’t a technique. It’s advice. Or wishful thinking.

  2. 2.2 Ensure that the tool automatically generates valid markup.

    Pass.

    Techniques

    • Ensure that the markup produced by the tool, in any of its supported languages, is valid.

    Pass.

    • Publish proprietary language specifications or DTD’s on the Web, to allow documents to be validated.

    Not applicable.

    • Use namespaces and schemas to make documents that can be automatically transformed to a known markup language.

    Not applicable, also incomprehensible.

  3. 2.3 If markup produced by the tool does not conform to W3C specifications, inform the author.

    Techniques

    • To minimally meet this checkpoint, a tool must inform the author that the markup produced does not conform to W3C specifications (e.g. statement on the saving dialog, an alert that is displayed following a save or inline highlighting through the use of style sheets, etc.).

    Fail, I suppose. If you select “automatically correct invalidly-nested XHTML automatically” in your Options, then this is not applicable. If you don’t, WordPress fails.

    • If the tool produces inaccessible markup, whether it is valid or not, see ATAG10 4.1 for checking techniques.

    Not applicable, and also much too general. Really, this is like saying “If you meet all our criteria, we may nonetheless force you to go back and fix all your content.” In a very indirect and impotent way, this criterion is trying to say that a valid document might be nonsemantic or inaccessible, but this isn’t a “technique”; it’s a badly-worded warning about a scenario it cannot quite get straight.

Guideline 3. Support the creation of accessible content

  1. 3.1 Prompt the author to provide equivalent alternative information (e.g., captions, [audio] descriptions, and collated text transcripts for video).

    Techniques

    • Provide a preview mode that displays alternative content.

    Not applicable. It’s self-contradictory. alt texts are to be displayed if the user agent “cannot display images, forms, or applets.” You can’t “preview” the blog entry, complete with the image you wanted, and also the alt text; it’s one or the other.

    I assume ATAG authors were acting as though IE/Win’s implementation of alt text – errantly displaying it as a tooltip – were actually correct. I assume they thought that you could look at the image and also read the tooltip. Apart from the fact that such a practice is inaccessible to many people, the approach is, quite simply, wrong. (A later checkpoint, 4.1, states: “Provide an editing view that shows equivalent alternatives in the main content view to make it clear that they are necessary. This will make it obvious when they are missing.” Again, you can’t show both.)

    Advise all authoring-tool manufacturers to ignore this checkpoint.

    • Prompt the author to provide equivalent alternative information.

    Pass for images, not applicable for everything else (since WordPress’s toolbar allows for image insertion only).

  2. 3.2 Help the author create structured content and separate information from its presentation.

    Fail, if you want to go through the exhaustive list ATAG uses. WordPress fails on the following criteria:

  3. 3.3 Ensure that prepackaged content conforms to the Web Content Accessibility Guidelines 1.0.

    Not applicable. You’re the author; you’re the one creating the content; you’re doing the “prepackaging” of things like images, not WordPress.

  4. 3.4 Do not automatically generate equivalent alternatives. Do not reuse previously authored alternatives without author confirmation, except when the function is known with certainty.

    This one’s rather tricky, not to mention self-contradictory. To put it in its most useful case: Don’t give people alt texts automatically. Except yes, go ahead, do that if you’re really sure you’re matching up the right alt text with the right image.

    Techniques

    • If the author has not specified an alternative equivalent, default to leaving out the relevant attribute, rather than including the attribute with no value or with automatically-generated content.

    Fail. If you don’t enter an alt text, you get alt="" instead of nothing. (As there is no call for spacer GIFs in WordPress, which would require alt="", defaulting to that attribute amounts to a failure.)

    • If human-authored equivalent alternatives may be available for an object..., it is appropriate for the tool to offer these to the author as defaults.

    Fail. WordPress does not store a repository of e.g. alt texts.

    • The function of objects is considered to be known with certainty when they are used throughout a Web site in a standard way (e.g., graphical navigation bars). In this case, the objects should have standard alternative information. Where an object has already been used in a document, the tool should offer the alternative information that was supplied for the first or most recent use as a default. If the user changes the alternative content, they might be asked whether all instances of the object should have their alternative content updated with the new value.

    Not applicable.

  5. 3.5 Provide functionality for managing, editing, and reusing alternative equivalents for multimedia objects.

    Fail.

Guideline 4. Provide ways of checking and correcting inaccessible content

  1. 4.1 Check for and inform the author of accessibility problems.

    Fail.

  2. 4.2 Assist authors in correcting accessibility problems.

    Fail.

  3. 4.3 Allow the author to preserve markup not recognized by the tool.

    Pass.

  4. 4.4 Provide the author with a summary of the document’s accessibility status.

    Fail.

  5. 4.5 Allow the author to transform presentation markup that is misused to convey structure into structural markup, and to transform presentation markup used for style into style sheets.

    Fail.

Guideline 5. Integrate accessibility solutions into the overall “look and feel”

  1. 5.1 Ensure that functionality related to accessible authoring practices is naturally integrated into the overall look and feel of the tool.

    From what I can tell, pass.

  2. 5.2 Ensure that accessible authoring practices supporting Web Content Accessibility Guidelines 1.0 Priority 1 checkpoints are among the most obvious and easily initiated by the author.

    From what I can tell, pass.

Guideline 6. Promote accessibility in help and documentation

  1. 6.1 Document all features that promote the production of accessible content.

    Fail. You can search the WordPress documentation and find, for example, advice to “include ALT and TITLE descriptions on links and images” in order to “be compliant with Web standards for accessibility” (except that alt and title have to be in lower case to be “compliant”). But there is no accessibility section.

    Recommend that the documentation homepage create a prominent accessibility section and that actual page list the ATAG techniques’ pair of wordy sample questions (“Ensure that the help system can answer the following: ‘What features of the tool encourage the production of accessible content?’ and ‘How are these features used?’ ”). Let’s humour them here.

  2. 6.2 Ensure that creating accessible content is a naturally integrated part of the documentation, including examples.

    Bare pass. Many of the ATAG techniques are vastly overblown and unworkable, like “Provide examples of all WCAG 1.0 accessibility requirements (including priority 2 and 3).” We don’t have all day, and we aren’t a reference book for WCAG. We’re a blogging tool. The techniques are so overweening I’m willing to give WordPress a bare pass for having done anything in this area.

  3. 6.3 In a dedicated section, document all features of the tool that promote the production of accessible content.

    Fail.

Guideline 7. Ensure that the authoring tool is accessible to authors with disabilities

This one’s rather tricky, as it assumes an application running under an “operating system.”

  1. 7.1 Use all applicable operating system and accessibility standards and conventions ....

    Techniques

    Apparent pass.

    • Configurability
      • Allow users to create profiles.
      • Allow control of timing, colors, sizes, input/output devices and media.

    Pass for those two.

    • Allow users to reshape the user interface - customize toolbars, keyboard commands, etc.

    Fail.

    Not applicable. Impossible in a browser. (Have we learned nothing from the experience of accesskey?)

    • Document all keyboard bindings.

    Pass.

    • Provide customizable keyboard shortcuts for common functions.

    Fail.

    • Provide logical navigation order for the keyboard interface.

    Pass.

    • Avoid repetitive keying wherever possible.

    Too vague to evaluate. Blogging is all about typing; any “keying” for user interface is trivial by comparison.

    • Provide mouse access to functions where possible.

    Pass. It’s built into browsers.

    • Icons, Graphics, Sounds
      • Provide graphical (text) equivalents for sound warnings.
      • Allow sounds to be turned off.
      • Provide text equivalents for all audio.
      • Use icons that are resizable or available in multiple sizes.

    Not applicable.

    • Provide text equivalents for images/icons.

    Via the toolbar itself, yes. Pass.

    • Use customizable (or removable) colors/patterns.

    The interface is skinnable, so pass.

    • Ensure high contrast is available (as default setting).

    Fail. (Zoom layout, anyone?)

    Pass.

    I think this is a pass. Someone with better understanding of the API will have to check.

    • Documentation
      • Provide documentation for all features of the tool.

    Fail. Not “all” features are documented. This is perhaps an unattainable goal.

    • Ensure that help functions are accessible.

    Pass. They’re normal Web pages.

  2. 7.2 Allow the author to change the presentation within editing views without affecting the document markup.

    Browser-dependent. Most techniques in this checkpoint are inapplicable. The ones that are applicable are a pass. [I loved the bit about “Allow the author to create audio style sheets using a graphical representation rather than an audio one (with accessible representation, of course).” Has any system, anywhere, ever, complied with that? Is any system even in a category or provides a function that would oblige it to comply?]

  3. 7.3 Allow the author to edit all properties of each element and object in an accessible fashion.

    Pass.

  4. 7.4 Ensure that the editing view allows navigation via the structure of the document in an accessible fashion.

    Fail with caveats. Even fails the minimum: “To minimally satisfy this checkpoint, allow navigation from element to element.” If you think that doesn’t make any sense at all, you aren’t alone. Also requires accesskey to be used. Why don’t we just call this one inapplicable and superseded by common sense?

  5. 7.5 Enable editing of the structure of the document in an accessible fashion.

    This one’s so vague I interpret it as a pass.

  6. 7.6 Allow the author to search within editing views.

    Inapplicable and browser-dependent. If you think the list of already-written or draft posts is an “editing view,” then WordPress passes.

Version history

2006.01.30
Posted.

You were here: Homepage → Captioning and media access → Web accessibility → ATAG assessment of WordPress