sapnagroup blog

Synopsis: W3C has recommended some guidelines for accessibility in its report “Web Content Accessibility Guidelines 1.0″ published on 05/05/1999 (http://www.w3.org/TR/WAI-WEBCONTENT/). These guidelines explain how to make Web content accessible to people with disabilities. Following them will also make Web content more available to all users, whatever user agent they are using (e.g., desktop browser, voice browser, mobile phone, automobile-based personal computer, etc.) or constraints they may be operating under (e.g., noisy surroundings, under- or over-illuminated rooms, in a hands-free environment, etc.). Following these guidelines will also help people find information on the Web more quickly.

The guidelines are divided into 3 parts.

• Design/Content issues
• Coding issues
• Data entry issues

The guidelines are as follows

1. Provide equivalent alternatives to auditory and visual content.
   Key changes, provide a text equivalent for every non-text element (e.g., via “alt”, “longdesc”, or in element content.
   We need to provide “alt” text even for non seo elements which are a part of a design like a spacer element which ensures a fixed height.
   We also need to provide an auditory description of the important information of the visual track of a multimedia presentation, eg we need one on the podcast.
   Priority 1 – Design, Coding, Data entry
2. Don’t rely on color alone.
   eg 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 – Design, Coding
3. Use markup and style sheets
   e.g. avoid using images to represent text, in CSS, use ‘em’ or percentage lengths rather than ‘pt’ or ‘cm’, which are absolute units.
   As ideally we would want the design to appear exactly how we perceive it as a design element (i.e. exactly like the photoshop file sent), but in accessibility we would want the user to be able to control the text size etc. This also means we might noy be able to get the exact size as per the design sent.
   Priority 2 – Design, Coding, Data entry
4. Clarify natural language usage
   Basically this would include
   specifying the primary language of the document (Priority 3), indicating where the language change occurs (Priority 1, relevant on those documents which do not have all blocks translated and we have a mix of both English and eg French) and using html methods to expand each abbreviation or acronym in a document where it first occurs (Priority 3). Coding, Data entry.
5. Create tables that transform gracefully
   e.g. are
   Avoid using tables for layout (Priority 2), we will have to use divs everywhere now.
   All tabular information should have row and column headers (Priority 1)
   Coding, Data entry
6. Ensure that pages featuring new technologies transform gracefully.
   Organize documents so they may be read without style sheets, and when scripts, applets, or other programmatic objects are turned off or not supported (Priority 1)
   Coding
7. Ensure user control of time-sensitive content changes.
   e.g. Avoid elements which flicker (Priority 1), blink, refresh, move, redirect (Priority 2).
   Design, Coding
8. Ensure direct accessibility of embedded user interfaces.
   If an applet (created with either OBJECT or APPLET) requires user interaction (e.g., the ability to manipulate a physics experiment) that cannot be duplicated in an alternative format, make the applet directly accessible. We would suggest we avoid flash interfaces, or provide alternative links for the same.
   Mostly Priority 2 – Design, Coding.
9. Design for device-independence.
   e.g. Provide keyboard shortcuts to important links, form controls, and groups of form controls. This would make it easier to navigate.
   Priority 1 and 2 – Coding
10. Use interim solutions.
    Avoid popup, changes to current window, refresh etc.
    Use label code for identifying form elements.
    Use default values for forms elements.
    Priority 2 – Coding
11. Use W3C technologies and guidelines
    Use latest W3C technologies reviewed for accessibility
    Priority 2 – Coding, Data entry
12. Provide context and orientation information.
    Give titles to frames, Divide large blocks of information into more manageable groups etc
    Priority 2 – Coding
13. Provide clear navigation mechanisms.
    Clearly identify the target of each link, Provide metadata to add semantic information to pages and sites
    Priority 2 – Design, Coding

Conclusion: Making any website accessible for the disabled is probably as good as reworking on the entire website from the design/code point of view. (Code in all content on this page means Html code). This requires tests with images turned off and scripts /applets turned off and tested. It might be impossible to get the entire site 100% accessible, but we must atleast aim to make it mostly accessible. Priority 1 items are must, and if we can do most priority 2 items it would be good. All priority 3 items which are real easy can be done but not really mandatory.