Accessibility

Introduction

Web Accessibility and Interoperability is about making web content available to all users including those with special needs or disabilities.

ComWeb V4 was released in April 2005 to address emerging trends and guidelines in Web Content Management Systems (WCMS) and Web Publishing Systems.

Web Accessibility, Interoperability and Usability concepts and guidelines are often difficult to grasp - especially from a ComWeb user perspective, as ComWeb was designed for non-technical managers and authors, and typically addresses these issues automatically and seamlessly.

Current web standards and guidelines that should be understood to appreciate these issues include:

• the W3C Accessibility and Interoperability coding guidelines - which aim at making content available to all users regardless of ability/disability or technology,
• AGIMO guidelines - covering Australian Government web site branding, searching (eg the implementation of Dublin Core metadata), accountability and archival requirements, etc, and
• each organisations web standards including business rules for efficient management of web content, personnel and workflows that in turn ensure awareness, currency, accountability, security and the overall well-being and effectiveness of the web presence.

Accessibility and Interoperability

Web Accessibility is about enabling access to web based information. This is achieved by applying structured mark-up to content (information) in a manner that will allow a web browser, reader or software, to interpret and display information in an expected manner.

Web Interoperability is about using open (non-proprietary) standards, formats and protocols to allow all hardware (PCs, screen/voice readers, Braille readers, printers, tty devices, etc) and software (browsers, voice recognition, etc) to access the web. The major initiative to achieve this is the separation of content, structure, presentation and behaviour.

The general consensus on the best elements of Web Interoperability, as published in the WWW Wikipedia is:

• Structural and semantic mark-up with XHTML.
• CSS based layout with layout elements such as position and float.
• Separation of structure, presentation and behaviour in web pages.
• DOM scripting based on W3C DOM Standard and ECMAScript.

These concepts do not mean that information should look or operate the same in all browsers and devices and at all screen resolutions. Nor does it mean that styles, frames, features, movement, transitions, etc must be avoided as this could deprive the vast majority of the target audience from modern, effective presentation and navigation techniques.

If a page containing advanced display constructs is not accessibility compliant, an alternative method of display or a link to a text version of a graphics page, or an option to toggle between a text and mouse-only style menu, etc, is sufficient to satisfy web accessibility standards.

eg 1: The W3C Technology page shows a diagram, which itself has no descriptive text for those who cannot see or download the image. However the page contains a link to another page describing the image making the first page "Accessible".

eg 2: The ACT Scout site contains a "Latest News" portal. If JavaScript is enabled then this portal scrolls vertically and pauses between items. If JavaScript is disabled or not supported this portal does not scroll. When the portal obtains focus (though keyboard or mouseover) the scrolling stops. The scroll can be controlled manually via the scrollbar and the links contained respond to tab and back-tab. For devices that do not support scroll or even CSS, the mark-up does not use tables for layout and the structure is simply sequential.

Use a Print Preview to view the page with a print style sheet, or try Ctrl-Shift-S to view a ComWeb V4.2 page as a screen reader would process it without style sheets. See also how to view web pages without CSS.

This example shows that the same mark-up can be used to provide the same content to a fully enabled interactive device, a static print device or to a screen or Braille reader - concurrently. The content does not need to appear or operate the same in different browsers or devices to be Accessibility or Interoperability compliant. The information simply needs to be available and marked up according to a known standard; provided the device also complies to the standards, it should respond and display as expected.

Related material:

Architecture of the World Wide Web
W3C XHTML2 Working Group
Building Software That Is Interoperable By Design
Understanding Web Accessibility - Joe Clark
Web Content Management - so much more than Web Publishing

Standards

ComWeb V4.2 has been tested for compliancy with the mandatory guidelines for web accessibility and interoperability with validators from:

• the World Wide Web Consortium (W3C), and
• the HiSoftware Company (Cynthia Says) portal. This is a joint Education and Outreach project of HiSoftware, ICDRI, and the Internet Society Disability and Special Needs Chapter.

We also acknowledge the valuable review and input from Dr. Sofia Celic from Vision Australia.

We endeavour to satisfy the following standards:

Compliancy Standard	Validation Service	Level
XHTML 1.0 Ed 2	W3C XHTML	1.0 Transitional
CSS V1.0	W3C CSS	Client specified*
US DOD Section 508	none found	US DOD Section 508 and WCAG Priority 1
HiSoftware (Cynthia Says)	none found	Priority 1 (Mandatory)

* Different clients have different target audiences, be they intranet, internet, secure sites, etc.

While ComWeb produces the same accessibility compliant content layer for all audiences and devices, a CSS developer should confirm with the web site owner: the required target browsers, versions, screen metrics, etc to be considered for their specific presentation layer.

The more browsers and versions that need to be supported, the more effort and the higher the cost will be for both development and ongoing support.

Typically clients addressing an intranet only audience have a specified SOE browser and therefore do not need to fund multiple browser or version development and support.

Browser incompatibilities

Coding according to these standards is a tall ask for developers as different browser manufacturers often have varying levels of standards compliance. Most browsers:

• do not support or fully support the same standards,
• support additional commands unique to their browsers,
• interpret instructions differently, and
• contain bugs and therefore do not act as expected.

Just as a CSS developer comes to terms with known bugs and workarounds for target browsers, vendors release a new version. Unfortunately successive versions of the same browser are seldom fully backwards compatible as standards continue to evolve and new browser versions attempt to comply, fixing old bugs and introducing new bugs.

It is therefore impossible for a CSS developer to know whether a CSS developed for one browser/version will work properly with it's successor or another. To minimise the cost of ongoing CSS support, we recommend CSS are developed according to W3C standards, clients use an accessibility compliant browser and apply Service Packs regularly.

Refer Will the browser apply the rules?

Some clients request specific presentation controls which may be outside CSS standards and often unique to a browser brand and version.

While ComWeb can produce fully compliant code, some organisations simply do not wish to implement certain guidelines, or due to factors like training, awareness or the sheer volume of content, wish to transition implementation of the guidelines. ComWeb has configuration settings to cater for varying degrees of enforcement of some guidelines.

Content and Presentation

The ComWeb V4 WCMS facilitates Accessibility and Interoperability through separation of content from presentation.

The ComWeb Content layer provides user entered content in an organised, accessibility compliant structure which is identical for all sites and all pages for each version. Sufficient mark-up is interleaved in this structure to allow the Presentation layer to reference specific content structures.

Within the Content Layer, content is drawn as XML and processed through an XSLT. The resultant xHTML structure is delivered to the user's browser. The browser considers the device required (screen, printer, tty, etc), renders the XHTML using the appropriate CSSs then runs any behavioural script.

As standards change, or new versions of browsers expect/require a different mark-up, it is a simple matter to update either the ComWeb structure or presentation without having to republish or update content. This allows ComWeb to adapt to new standards and browser versions - thus future proofing the system and protecting the most valuable asset - a client's data.

A ComWeb presentation layer structure map is available to enable graphic artists and CSS developers to develop or update the Presentation layer for ComWeb sites. Please email our helpdesk advising the client site in question, to enable us to provide the appropriate version.

In ComWeb the Presentation Layer controls site and page layout, branding, presentation, navigation, operation and behaviour through Cascading Style Sheets and JavaScript.

An appropriate combination of the Content and Presentation layers will allow users to access information, even if it means using a special browser, setting, resolution, or some other assistive technology, eg. a voice or Braille reader.

Related marterial:

Architecture of the World Wide Web
Web Content Management - so much more than Web Publishing

Investigating issues

For the reasons explained above, new browsers and new versions of browsers, do not necessarily interpret the Presentation Layer as current browsers. While CompuCraft can be engaged to research and advise, clients with such queries may first determine if differences require a change to the Presentation layer (CSS or JS), otherwise an updated structural mark-up may be required.

Disabling Style Sheets

Since the release of ComWeb V4.2.2, a special key sequence of Ctrl-Shift-S has been implemented to disable styles and revert to a native browser view. If the information required is available with CSS disabled, yet not with CSS enabled (reapply with Refresh or F5 in IE), it suggests a presentation layer issue and not a content layer issue.

Use Ctrl-Shift-S to view a ComWeb V4.2 page without styles or see how to view web pages without CSS.

Checking for W3C xHTML Accessibility compliancy

CompuCraft warrants that ComWeb will produce accessibility compliant code - this is tested at time of each ComWeb release.

To determine if a page is valid:

• right (alternate)-click on the page being viewed
• select view source from the context menu and copy the text to the clipboard (Ctrl-A, Ctrl-C)
• go to the W3C Mark-up Validation Service web site
  

• click in the direct input box, paste the clipboard contents(Ctrl-V) and click "Check".

If the code validates, then the structure is OK.
If the code fails to validate, ensure it is not the "user in-line code" which is beyond the control of ComWeb.
If in ComWeb generated code, save the source to a text file and email it to CompuCraft for examination.

Note - after checking the XHTML structure you should also check the CSS for Accessibility on the same site.

Reporting issues

If you are in our target audience (refer home page) and have difficulty operating or accessing this site or other ComWeb sites, please provide the following details to assist us in assisting you:

• the specific compliancy standard and clause where you feel we do not comply with a mandatory guideline
• the brand and version of your current accessibility compliant browser, with the brand and version of any plug-in, (noting the browsers supported above)
• a screen capture* displaying the issue - if visual. If not obvious from the screen capture, some clear and concise explanation to assist us in understanding your particular issue.
• a copy of the source file(s)**,
• your name, email address and phone number to respond and discuss as required, and
• reason for priority if the matter is urgent.

* To capture the screen display: press Alt-PrintScreen (captures the current window to the clipboard), paste this into a new Paint file (or other graphics program), then save as a jpg. (JPGs are up to 1/1000 the size of a BMP).

** To copy the source files: use File, Save, and nominate a local drive (eg My Documents) and type of HTML. This should create both an HTML file and a folder by the same name containing any images, javascript and CSS files referenced in the HTML. We need this to recreate the issue and examine the underlying code.

If you are unsure, then please provide both the screen capture and the source files. Then email the above details and an attached ZIP of the supporting files to our helpdesk.

Access Keys

One of several Accessibility features in ComWeb is Access keys for non-mouse users. These are keys to skip to specific areas of the web site via a keyboard.
Access Keys generated in ComWeb V4.2 pages are:

Access Key	Location or Link	on this page
1	Link to this site's Home Page	No
2	Top of the current page	Yes
3	Navigation menu of the current page	Yes
4	Begining of the current page's content	Yes
5	Search feature (if available)	Yes
6	Link to the Site Map Page	No

If the link is on the current page the Access key will suffice, otherwise an enter is also required:

• PC/Windows: press alt + access key number to highlight link, then enter to go to the corresponding page.
• Macintosh: press control + access key number to highlight link, then return to go to the corresponding page.