Composr Tutorial: Helping improve site accessibility for disabled users

Written by Chris Graham

The W3C, the standards organisation responsible for core web standards, has a project, the web accessibility initiative (WAI), that defines a standard for the creation of accessible web pages: the web content accessibility guidelines (WCAG). In addition, U.S. federal agencies are required by law to meet section 508 guidelines on accessibility.

Accessibility is concerned with ensuring websites are accessible to those with differing needs, in particular those with disabilities. Naturally, a website cannot be made accessible to all forms of disability, but with some work, they can cater for a large proportion of disabled users, such as blind or partially-sighted users. The basic premise, is that things implied to by visual artefacts, such as colour and position, are not universal for people with various forms of impairment, and by making information explicit in your HTML mark-up ('semantic' mark-up, because the structure now extends to conceptual structure, to a degree), you can make your site more accessible to them; for example, by explicitly linking the text associated with an input form field, a blind user (who is without visual aids) knows, without difficulty, what the field is for.

Under U.K. law, and other jurisdictions, there is anti-discrimination legislation that covers the provision of services. It is arguable that this legislation covers designing websites such that they conform with accessibility standards. Therefore if you are a business operating in such a jurisdiction, it is highly advisable that you conform.

In addition to making a site accessible by the disabled, good accessibility practice also helps usability. For example,

by making sure that web pages are given a so-called semantic structure, they automatically become more usable on text-only web browsers. A system administrator needing to access an intranet externally via a remote console would find this particularly useful.
forms become more usable, as you do not need to click directly on the sometimes small check-boxes, radio-buttons, and lists to activate them: you can click on any part of the label as well. This makes filling in forms a lot quicker, as less precision mouse work is required.
A good way to test the quality of a website is to see if this is possible on it: on most it is not.
by improving navigation for those who cannot navigate between links as fast as others, navigation is also sped up for others. For example, by creating a site-map, everyone benefits.

Composr complies with the highest level of the WCAG (to the latest version at the time of writing, 1.0) guidelines, level 3. Few websites are close to reaching level 1, but our inbuilt webstandards checking technology allows Composr users to get an edge in this area. Composr also meets section 508 guidelines, the XHTML and CSS specification, as well as many other minor considerations that other software has no automated way of checking for. Composr conforms to these standards throughout – from screens that only users will view, up to those an administrator uses – and meets the highest level of the ATAG.

Table of contents

Composr Tutorial: Helping improve site accessibility for disabled users

Webmaster concerns

After you have decided on the layout of your website, and created appropriate pages, you will need to create a site-map. The site-map is linked to from the bottom of every Composr page, and you will see that Composr comes with a default place-holder.

The complexity of your site-map depends upon the complexity of your website. A small website may be able to just point the user to the left hand menu, while a large website should detail the full site structure, with links to all pages that should be directly accessible.

The checkpoint tables included in this document, under the template compliance section, include checkpoints that apply to webmaster rather, or in addition to, the design of Composr itself. Therefore it is important to read this table and act in accordance with it. Webmaster concerns are mainly:

Fill in optional captions for media
Layout your site in a clear and consistent manner
Do not fill your site with multimedia without providing information about that multimedia
Avoid using Comcode tags that make the page dynamic in the user web browser, such as [ticker] and [jumping]

It is possible to use Comcode in such a way that a page becomes invalid. Usually this is not something that would be accidentally triggered, as there is a correlation between common sense and webstandards checking for most of these scenarios. An example error would occur if you put a [block] tag inside a [url] tag: intuitively, this does not make sense, as a block could not be a sensible link title.

It is also possible to degrade validation by creating different items of content that share the same title. For example, if two forums share the same title, it is likely that on the forum page there will by an error due to two separate links sharing the same link text. Composr avoids this when it is reasonable to think that two links may share a title, by providing additional distinguishing information for the link, but does not universally distinguish all links in the portal in such a way, as to do so would merely make the link-text closer to that of the URL, undermining the accessibility in itself by making them overly complex. To work-around this, simply try to choose distinctive titles for your content.

Template compliance

This section will detail Composr compliance with the guidelines, with any relevant notes. The check-list is taken directly from the W3C specification. If the templates are edited, and conformance is still desired, then it is recommended that you enable the webstandards checker while editing templates (only staff will see the error messages even when it is enabled): the webstandards checker is of enormous practical assistance in finding and describing errors, for all relevant specifications. The table will detail any special information relating to how Composr is designed to work with some of the more tricky requirements.

Priority 1 checkpoints

In General (Priority 1)
1.1 Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video.	Composr webstandards checker ensures this is done.
2.1 Ensure that all information conveyed with color is also available without color, for example from context or markup.	Composr complies. This applies to web-masters.
4.1 Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions).	This applies to web-masters.
6.1 Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document.	Composr complies.
6.2 Ensure that equivalents for dynamic content are updated when the dynamic content changes.	Composr supports ARIA.
7.1 Until user agents allow users to control flickering, avoid causing the screen to flicker.	The webmaster should avoid such content, including usage of the [ticker] Comcode tag, and possibly the [jumping] Comcode tag.
14.1 Use the clearest and simplest language appropriate for a site's content.	This applies to web-masters.
And if you use images and image maps (Priority 1)
1.2 Provide redundant text links for each active region of a server-side image map.	Not applicable.
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.	Composr complies.
And if you use tables (Priority 1)
5.1 For data tables, identify row and column headers.	Composr webstandards checker ensures this is done.
5.2 For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells.	Composr webstandards checker ensures this is done.
And if you use frames (Priority 1)
12.1 Title each frame to facilitate frame identification and navigation.	Composr webstandards checker ensures this is done.
And if you use applets and scripts (Priority 1)
6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.	Composr supports ARIA. This guideline is outdated and does not appear in the newer (simpler) version of WCAG.
And if you use multimedia (Priority 1)
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 applies to web-masters.
1.4 For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation.	This applies to web-masters.
And if all else fails (Priority 1)
11.4 If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page.	Composr can provide an accessible page, and the user can add such a link if they wish.

Priority 2 checkpoints

In General (Priority 2)
2.2 Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen. [Priority 2 for images, Priority 3 for text].	Composr is designed to high graphic standards that precludes such bad contrast. This applies to web-masters.
3.1 When an appropriate markup language exists, use markup rather than images to convey information.	Composr complies (SVG statistics, for example).
3.2 Create documents that validate to published formal grammars.	Composr webstandards checker ensures this is done.
3.3 Use style sheets to control layout and presentation.	Composr complies.
3.4 Use relative rather than absolute units in markup language attribute values and style sheet property values.	Composr complies. Note that this does not totally preclude using absolute units, just when they are better replaced with relative units. Composr webstandards checker prevents fonts from having absolute size.
3.5 Use header elements to convey document structure and use them according to specification.	Composr complies.
3.6 Mark up lists and list items properly.	Composr complies (menus for example).
3.7 Mark up quotations. Do not use quotation markup for formatting effects such as indentation.	Composr complies (main_quotes for example). This applies to web-masters.
6.5 Ensure that dynamic content is accessible or provide an alternative presentation or page.	Composr supports ARIA.
7.2 Until user agents allow users to control blinking, avoid causing content to blink (i.e., change presentation at a regular rate, such as turning on and off).	See 7.1.
7.4 Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing pages.	Composr complies, except for hidden refreshing iframe's which are necessary to specific functions.
7.5 Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages automatically. Instead, configure the server to perform redirects.	Unlike most web systems, Composr will not show “you are being redirected” pages. Refresh is either automatic (often via the location header), or a user must confirm by clicking a continue link.
10.1 Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user.	Composr complies. Note that despite the wording of this check-list entry, it is allowed to cause a pop-up when there is sufficient warning, which Composr always provides.
11.1 Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported.	Composr complies.
11.2 Avoid deprecated features of W3C technologies.	Composr webstandards checker ensures this is done.
12.3 Divide large blocks of information into more manageable groups where natural and appropriate.	This applies to web-masters.
13.1 Clearly identify the target of each link.	Composr webstandards checker ensures this is done.
13.2 Provide metadata to add semantic information to pages and sites.	Composr webstandards checker ensures this is done.
13.3 Provide information about the general layout of a site (e.g., a site map or table of contents).	Composr provides automatic sitemap generation functionality, a default sitemap page, and an advanced menu editor.
13.4 Use navigation mechanisms in a consistent manner.	Composr complies.
And if you use tables (Priority 2)
5.3 Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version).	Composr complies. Note that layout tables are allowed, but Composr hardly uses them anywhere (only when a CSS limitation needs to be overcome).
5.4 If a table is used for layout, do not use any structural markup for the purpose of visual formatting.	Composr complies.
And if you use frames (Priority 2)
12.2 Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone.	Composr complies.
And if you use forms (Priority 2)
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.	Composr webstandards checker ensures this is done. When attaching a label is visually impractical, an invisible label is rendered: this should still be available for technologies such as screen-readers, but be invisible under ordinary use.
12.4 Associate labels explicitly with their controls.	Composr webstandards checker ensures this is done.
And if you use applets and scripts (Priority 2)
6.4 For scripts and applets, ensure that event handlers are input device-independent.	Composr webstandards checker ensures this is done where possible, and Composr complies.
7.3 Until user agents allow users to freeze moving content, avoid movement in pages.	See 7.1.
8.1 Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies [Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2.]	Composr supports ARIA.
9.2 Ensure that any element that has its own interface can be operated in a device-independent manner.	See 6.4. Some features would not be available without a mouse, but these are always unnecessary.
9.3 For scripts, specify logical event handlers rather than device-dependent event handlers.	See 6.4.

Priority 3 checkpoints

In General (Priority 3)
4.2 Specify the expansion of each abbreviation or acronym in a document where it first occurs.	Composr complies. This applies to web-masters.
4.3 Identify the primary natural language of a document.	Composr webstandards checker ensures this is done.
9.4 Create a logical tab order through links, form controls, and objects.	Composr complies, and to an extent, the Composr webstandards checker ensures this is done. Note that most applicable elements have no specific tab-order, as the automatic order suits.
9.5 Provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls.	Composr complies.
10.5 Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links.	Composr webstandards checker ensures this is done. In order to achieve it, <span style=”display: none”>, </span> is often used in templates. This is invisible, but semantically present: hence allowing visual style to be unaffected, but providing an aid for screen-readers.
11.3 Provide information so that users may receive documents according to their preferences (e.g., language, content type, etc.)	Composr complies (the language block, for example).
13.5 Provide navigation bars to highlight and give access to the navigation mechanism.	Composr complies (the menu system, for example).
13.6 Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group.	Composr complies. This applies to web-masters.
13.7 If search functions are provided, enable different types of searches for different skill levels and preferences.	Composr complies (search page has advanced options, but not immediately available).
13.8 Place distinguishing information at the beginning of headings, paragraphs, lists, etc.	This applies to web-masters.
13.9 Provide information about document collections (i.e., documents comprising multiple pages.).	Composr complies. This applies to web-masters.
13.10 Provide a means to skip over multi-line ASCII art.	This is a very particular point. Not applicable.
14.2 Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page.	This applies to web-masters.
14.3 Create a style of presentation that is consistent across pages.	Composr complies. This applies to web-masters.
And if you use images and image maps (Priority 3)
1.5 Until user agents render text equivalents for client-side image map links, provide redundant text links for each active region of a client-side image map.	Composr complies.
And if you use tables (Priority 3)
5.5 Provide summaries for tables.	Composr webstandards checker ensures this is done. Standard layout strings show the form of the table. Layout tables have an empty summary.
5.6 Provide abbreviations for header labels.	Composr webstandards checker ensures this is done when an abbreviation is needed (long header labels). To achieve this, we often put a code-name into the <th> abbr attribute. While this is biased to English, it is an abbreviation and does solve the problem at hand in an appropriate way.
10.3 Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns.	Assistive technologies now provide this.
And if you use forms (Priority 3)
10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas.	Assistive technologies now provide this.

Example accessibility problems

Abused markup

Web designers often abuse HTML tags in order to achieve visual side-effects that those tags come with.
For example:

Code (`HTML`)

<blockquote>
This is indented.
</blockquote>

The blockquote tag is intended to markup quoted information, but has the side-effect of indenting text. Web browser technology designed to assist those with disabilities may make use of the so-called 'semantics' of a documents markup in order to better express it to the user, but the user would be misled in situations where such markup was used incorrectly.

The correct way to achieve the indentation effect would be to use CSS as follows:

Code (`HTML`)

<div style="padding-left: 50px">
This is indented.
</div>

Preferably, the CSS information would be moved into its own named class, with the properties stored in the global.css styled sheet (so that they may be easily edited at a later date, or overridden if the user has their own specially designed 'override' style sheet), but this is not nearly as critical as the misuse of markup.

Confusing text

Writing skills are important for a website targeted at the general-public, and especially so when a segment of the audience have cognitive disorders.
Take the following text, for example:

Introduction
Here you will find forums, chatrooms, and I will post the latest news that our team has for you.

We especially envision provisioning the latest information pertaining to Consuperrabiotriaxilator for the esteemed reader.

More details
This is the website of Virtual Mega Cyber Products, developers of Consuperrabiotriaxilator.

While this example is somewhat ridiculous, it is not actually far from the reality of many ill-considered websites.
Major writing errors in this example include:

Not providing any useful information in the titles. These occupy large amounts of space, and an opportunity wasted if not used effectively.
Assuming the reader knows information that they probably do not.
Not providing the most key information near the start.
Using pretentious language that only aids to confuse rather than impress.
Using complex terminology without explaining it.

These issues go beyond accessibility, and are very relevant to the marketing of your website: never over-estimate the attention span of your reader, or their ability to realise what is obvious to you.

Invalid markup

This is an example of an invalid XHTML-strict fragment:

Code (`HTML`)

<p><font color=red>First paragraph.
<p>Second paragraph.</font>

This markup is incorrect for a number of reasons:

All tags that are opened must always be closed, yet the two p tags have not been.
Tags must not overlap, yet the font tag is defined in the first paragraph, and extends after that paragraph has ended.
The font tag is not present in XHTML-strict.
All attributes must be quoted, while the color attribute is not.

While none of these issues are directly related to accessibility, the strict adherence to the latest XHTML and CSS specifications increases the accessibility as the standards are increasingly designed for it.
For example:

Clearly defining where tags start and end allows user agents more certainty over the correct interpretation, and hence they can be better expressed non-visually. While there are rules for interpreting HTML in a way that is fully expressed, there is no guarantee that the author's intent is that of the interpretations assumption.
Overlapping tags might make sense visually, but are unnecessarily complex when expressed non-visually.
CSS is preferable to the use of the font tag because the user may override the presentation with that of their own; for example, a user could increase the contrast between certain colours by overriding part of a CSS class.
Using a simple and consistent strict grammar makes document markup easier to read and understand, and hence reduces the chance of making other errors due to the reduction in distraction.

Omitted accessibility information

This is an example of a table that has not been marked up in an accessible fashion:

Code (`HTML`)

<table class="results-table">
<tr>
<td>Name</td>
<td>Ronald</td>
</tr>
<tr>
<td>Age</td>
<td>32</td>
</tr>
<tr>
<td>Location</td>
<td>Leeds</td>
</tr>
</table>

If visually scanned, it is obvious how this table is laid out. However, non-visual user agents would read out each data cell with equal prominence and the user would need to build up an understand of it themselves based on this raw 'linearised' stream of information; this is especially problematic when data tables and layout tables are mixed without any distinguishing marks.
If properly marked-up, the user would get an understand with greater ease. While this might seem a minor issue, it is in fact very important because it lowers the burden for a user who is likely to have many other problems that are less avoidable.

A properly marked-up version, using Composr conventions, would look as follows:

Code (`HTML`)

<table class="map-table results-table">
<tr>
<th>Name</th>
<td>Ronald</td>
</tr>
<tr>
<th>Age</th>
<td>32</td>
</tr>
<tr>
<th>Location</th>
<td>Leeds</td>
</tr>
</table>

Accessible authoring

You will find a number of options in Admin Zone > Setup > Configuration > Accessibility options, for tuning the webmaster experience to meet particular accessibility requirements.

Feedback

Please rate this tutorial:

Have a suggestion? Report an issue on the tracker.

Composr Tutorial: Helping improve site accessibility for disabled users

Webmaster concerns

Template compliance

Priority 1 checkpoints

Priority 2 checkpoints

Priority 3 checkpoints

Example accessibility problems

Abused markup

Code (`HTML`)

Code (`HTML`)

Confusing text

Introduction

More details

Invalid markup

Code (`HTML`)

Omitted accessibility information

Code (`HTML`)

Code (`HTML`)

Accessible authoring

Concepts

See also

Feedback

Statistics

Composr Tutorial: Helping improve site accessibility for disabled users

Webmaster concerns

Template compliance

Priority 1 checkpoints

Priority 2 checkpoints

Priority 3 checkpoints

Example accessibility problems

Abused markup

Code (HTML)

Code (HTML)

Confusing text

Introduction

More details

Invalid markup

Code (HTML)

Omitted accessibility information

Code (HTML)

Code (HTML)

Accessible authoring

Concepts

See also

Feedback

Statistics

Code (`HTML`)

Code (`HTML`)

Code (`HTML`)

Code (`HTML`)

Code (`HTML`)