« Back to Tutorial Index

Skip navigation

ocPortal Tutorial: Helping improve site accessibility for disabled users

Written by Chris Graham, ocProducts

ocPortal accessibility compliance

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.

ocPortal in a text-mode browser

Accessibility is concerned with ensuring web sites are accessible to those with differing needs, in particular those with disabilities. Naturally, a web site 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.

ocPortal accessibility compliance

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.

ocPortal has an inbuilt validator to ensure high compliance against many standards

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.

ocPortal 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 validating technology allows ocPortal users to get an edge in this area. ocPortal 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. ocPortal 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

ocPortal Tutorial: Helping improve site accessibility for disabled users
ocPortal Tutorial: Helping improve site accessibility for disabled users

Web master concerns

ocPortal displays HTML and any errors in an easily readable fashion

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 ocPortal page, and you will see that ocPortal 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, whilst a large website should detail the full site structure, with links to all pages that should be directly accessible.

This image displays how colour can be used to improve usability, but without it being required to understand an interface

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 ocPortal itself. Therefore it is important to read this table and act in accordance with it. Web-master 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 validation 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. ocPortal 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 ocPortal 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 XHTML-validator whilst editing templates (only staff will see the error messages even when it is enabled): the validator is of enormous practical assistance in finding and describing errors, for all relevant specifications. The table will detail any special information relating to how ocPortal is designed to work with some of the more tricky requirements.

Please note that whilst ocPortal works without Javascript, some times alternatives have to be used. For example, the menu editor requires Javascript, so if Javascript is not usable, the [menu] Comcode tag must be used instead.

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.	ocPortal validator ensures this is done.
2.1 Ensure that all information conveyed with color is also available without color, for example from context or markup.	ocPortal 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.	ocPortal complies.
6.2 Ensure that equivalents for dynamic content are updated when the dynamic content changes.	ocPortal works without Javascript.
7.1 Until user agents allow users to control flickering, avoid causing the screen to flicker.	The web-master 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.	ocPortal complies.
And if you use tables (Priority 1)
5.1 For data tables, identify row and column headers.	ocPortal validator 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.	ocPortal validator ensures this is done.
And if you use frames (Priority 1)
12.1 Title each frame to facilitate frame identification and navigation.	ocPortal validator 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.	ocPortal works without Javascript.
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.	ocPortal 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].	ocPortal 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.	ocPortal complies (SVG statistics, for example).
3.2 Create documents that validate to published formal grammars.	ocPortal validator ensures this is done.
3.3 Use style sheets to control layout and presentation.	ocPortal complies.
3.4 Use relative rather than absolute units in markup language attribute values and style sheet property values.	ocPortal complies. Note that this does not totally preclude using absolute units, just when they are better replaced with relative units. ocPortal validator prevents fonts from having absolute size.
3.5 Use header elements to convey document structure and use them according to specification.	ocPortal complies.
3.6 Mark up lists and list items properly.	ocPortal complies (menus for example).
3.7 Mark up quotations. Do not use quotation markup for formatting effects such as indentation.	ocPortal 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.	ocPortal works without Javascript.
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.	ocPortal 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, ocPortal 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.	ocPortal 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 ocPortal always provides.
11.1 Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported.	ocPortal complies.
11.2 Avoid deprecated features of W3C technologies.	ocPortal validator 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.	ocPortal validator ensures this is done.
13.2 Provide metadata to add semantic information to pages and sites.	ocPortal validator ensures this is done.
13.3 Provide information about the general layout of a site (e.g., a site map or table of contents).	ocPortal provides a template for the web-master to fill in.
13.4 Use navigation mechanisms in a consistent manner.	ocPortal 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).	ocPortal complies. Note that layout tables are allowed, but ocPortal 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.	ocPortal 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.	ocPortal 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.	ocPortal validator 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.	ocPortal validator 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.	ocPortal validator ensures this is done where possible, and ocPortal 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.]	ocPortal works without Javascript.
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.	ocPortal complies. This applies to web-masters.
4.3 Identify the primary natural language of a document.	ocPortal validator ensures this is done.
9.4 Create a logical tab order through links, form controls, and objects.	ocPortal complies, and to an extent, the ocPortal validator 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.	ocPortal complies.
10.5 Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links.	ocPortal validator 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.)	ocPortal complies (the language block, for example).
13.5 Provide navigation bars to highlight and give access to the navigation mechanism.	ocPortal 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.	ocPortal complies. This applies to web-masters.
13.7 If search functions are provided, enable different types of searches for different skill levels and preferences.	ocPortal 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.).	ocPortal complies. This applies to web-masters.
13.10 Provide a means to skip over multi-line ASCII art.	It is very strange that this is in the standard. 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.	ocPortal 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.	ocPortal complies.
And if you use tables (Priority 3)
5.5 Provide summaries for tables.	ocPortal validator 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.	ocPortal validator 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. Whilst 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

Flash

Macromedia Flash is inherently inaccessible to those with certain kinds of disabilities, because it assumes that the web browsing is a visual, mouse-orientated experience. Whilst Flash does not deserve harsh criticism for this (almost all of traditional desktop interfaces make the same assumption), it is inferior to well written (X)HTML from the accessibility perspective. HTML's document model of interfaces provides the 'semantic' structure that allows web pages to be accessible.

Therefore, to make an accessible website, Flash should be avoided for anything other than auxillary usage that XHTML could not reasonably achieve.

Javascript

As with Flash, the usage of Javascript often degrades from the clean document model of (X)HTML that allows accessibility. As there is no way for a web browser to distinguish between Javascript that does operate with alternative user interfaces and Javascript that does actually actively detract from accessibility of the plain document, it must be assumed that Javascript might be fully disabled.

Hence, interfaces that rely on Javascript, such as core navigation menus that are dynamically constructed from nothing using Javascript, would not be acceptable for an accessible website. In contrast, ocPortal does have optional Javascript powered menus, but they are primarily grounded in actual predefined XHTML and hence accessible.

Abused markup

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

Code


			<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


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

Preferably, the CSS information would be moved into it's 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 targetted 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, chat rooms, 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.

Whilst 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


			<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, whilst the 'color' attribute is not.

Whilst 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. Whilst 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 consistant 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.

Ommited accessibility information

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

Code


			<table class="solidborder">
   <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. Whilst this might seem a minor issue, it is infact 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 ocPortal conventions, would look as follows:

Code


			<table class="solidborder" summary="{!MAP_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>

Concepts

WAI: Web Accessibility Initiative; a group working under the W3C who are the official standards organisation behind the world wide web.
WCAG: Web Content Accessibility Guidelines, as written under the WAI.
Semantic: Roughly means 'meaning', and often used as the opposite to 'syntax'. Semanticly constructed web pages have well considered structural definition, leading to some aspects of meaning in the layout.
Section 508: Accessibility legislation similar to WCAG, that applies to US federal institutions.
ATAG: Authoring Tool Accessibility Guidelines.

Is this tutorial insufficient?

If you think this tutorial needs work (maybe we didn't explain things well enough?) please let us know.

Keyboard shortcuts

Mozilla, you screwed upWhat we do with feedbackAn online booking engineHow to debug an infinite recursionIt's good to be challenged

Privacy · Feedback · Web Hosting Services provided by eLief

ocPortal Tutorial: Helping improve site accessibility for disabled users

Web master concerns

Template compliance

Priority 1 checkpoints

Priority 2 checkpoints

Priority 3 checkpoints

Example accessibility problems

Flash

Javascript

Abused markup

Code

Code

Confusing text

Introduction

More details

Invalid markup

Code

Ommited accessibility information

Code

Code

Concepts

See also

Is this tutorial insufficient?