Loading...
 

WebAccessibilityInitiativeDev

The Web is for everybody!

What is Web Accessibility Compliance?

Web Accessibility Compliance works to ensure equal opportunity for all, as defined by the W3C Web Accessibility Initiative & Section 508. The Tiki Team firmly believes in providing equal opportunity, access, and availability to all.


If you're a developer, or interested in developing, consider that your users may:

  • not be able to see, hear, move, or process some types of information easily or at all
  • not be able to easily read or comprehend text
  • not be able to use a keyboard or mouse
  • have a text-only screen, a small screen, or a slow Internet connection
  • not be able to speak or understand the language written text
  • work in an environment where eyes, ears, or hands are not free from interference (i.e. driving to work, working in a loud environment, etc.)
  • have an early version of a browser, a different browser entirely, a voice browser, or a different operating system


These considerations are just a handful of differences to be mindful of when developing Tiki.

Source: http://www.w3c.org


Table of contents

WAI, Section 508 and Related Legislation

Introduction

Disability rights laws are intended to remove barriers, and provide equal opportunity & access for all. The Americans with Disabilities Act (ADA) required removal of physical barriers – wheelchair ramps, curb cuts, Braille elevator buttons, etc.

The World Wide Web presents a new set of challenges to help make another aspect of life accessible for all. Access to electronic and information technology for people with disabilities is a significant law and policy issue.

Statistics

So what if users with disabilities cannot access a website?

  • Harris Poll survey found that Americans with disabilities spend twice as much time on the Internet as those without disabilities.
  • World Health Organization, 2000, reports the number of persons with disabilities:
    • 500 million worldwide, 7-10% of population
    • 54 million in US, 20% of the population
  • Number continues to grow as demographics change (difficult to accurately predict)
  • 30% of all Web users do not load images
  • Search engines are effectively blind and this is how most users find information.
  • Temporary disabilities are not included in the statistics

Inaccessibility = Barriers to Information

Inaccessible technology interferes with an individual's ability to obtain and use information quickly and easily. Accessible web design removes barriers so that as many people as possible can access & have equal opportunity to work interactively online.

  • Puts people at a disadvantage by not allowing them to participate online.
  • Limits freedom to work online
  • Limits people you can get your message to – it's good business to be more inclusive
  • Barrier-free designs opens doors to this greater audience

Rehabilitation Act

Section 508: What’s Covered

Section 508: What’s not Covered

Accessibility Initiatives

Related Legislation

Why Accessibility Matters

Introduction

Usability vs. Accessibility

Many people confuse usability and accessibility. In fact, they’re two very similar concepts, but each is also very distinct. Often times people think that a usable site is accessible (and vice versa). While the two are not exclusive, it is important to understand the difference.

  • Usability means that a website is intuitive and easy to use
  • Accessibility means a website is as barrier-free as possible
  • Section 508 and accessibility
    • Section 508 does not define “accessible???
    • Section 508 provides a baseline for as many people as possible


Poor design excludes people from being able to utilize the web. Cognitive disabilities create barriers and are often considered under one (or more) of the three disabilities identified by Section 504.

Section 508 was intended to remove barriers, providing equal access & accessibility for all. As more developers meet this challenge, more websites will provide more ways of interfacing with various assistive technology devices.

Types of Disabilities

The following are the most common disabilities identified in Section 508.
  • Visual
    • Blindness (complete loss of sight)
    • Legally blind (not completely blind)
    • Weak vision, dimness, tunnel vision, extreme near or far sightedness
    • Color blindness
  • Auditory
    • Deaf (complete loss of hearing)
    • Hard of hearing
    • High/low frequency hearing loss
  • Mobility
    • Repetitive Stress Injuries (RSI)
    • Arthritis
    • Stroke
    • ALS (Arterial Lateral Sclerosis; Lou Gehrig’s Disease)
    • Spinal Cord Injuries
    • Loss of limbs or digits

Mobility disabilities, either permanent or short-term, limit ability to use a mouse. Since manipulating a mouse cursor can be laborious, providing a feature such as the option to skip repetitive navigation links can help these users get to the content of a page more directly.

Assistive Technology (AT)

Assistive technology devices are designed to allow a person with a particular disability to interact with his environment.
  • Visual AT
    • Screen readers (such as JAWS or Window Eyes)
    • Braille displays (interprets the text on the screen into Braille characters)
    • Voice recognition
    • Screen enlargers/magnification (i.e. MAGic and Zoom Text)
    • High (or different) contrast settings (i.e. white text on a blue background)
  • Auditory AT
    • Hearing aids & other similar devices don’t impact web design significantly
    • Web developers should take note of how using multimedia can pose an obstacle to this audience
    • People with auditory difficulties require visual representation of auditory information
  • Mobility AT
    • Keyboard access
    • Breath control devices
    • Retinal scanning devices
    • Voice input/recognition

Benefits of Accessible Design

Many people may not use a graphical browser or may turn graphics off. This may be due to hardware limitations such as:
  • Older computers or browser versions
  • Slow modem connection
  • High per-minute charges for internet connection
  • Connection via a mainframe/dumb terminal
  • Wireless connection (i.e. cell phone or PDA)

Some users may prefer to read content rather than display a complex presentation format. By creating accessible websites, a greater audience is being reached, thereby extending the range of communication.

Developing Accessible Websites

Introduction

The focus of this presentation is on designing Web pages that are compliant with section 508. However, there are additional recommendations beyond section 508 that concern accessibility. Where applicable, these additional techniques are placed at the end of the appropriate section.

Keep it Separated

To design accessible websites one must separate the key elements of a page.


Distinguish the content and structure of a page, then separate it from the presentation (content versus layout):

• Content is what you say
• Structure is how you organize it

• Presentation is how it appears, feels, sounds

Section-508 Guidelines & Applying it to Tiki

Color

Although colorful elements can richly enhance a Web page for a sight-dependent user, the content must still be accessible to those who cannot interpret colors.


Guideline (c): Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.

  • Don’t rely on color alone to convey meaning: use it as a secondary indicator only
  • Though not required by 508, use high-contrast color schemes
    • Background patterns and color should contrast well with lettering
    • Avoid similar color combinations in the interface and graphics
    • Never contrast red and green

CSS

All of the design and formatting issues discussed previously apply to the design of style sheets.


Guideline (d): Documents shall be organized so they are readable without requiring an associated style sheet.

  • CSS is designed to complement HTML by separating content from layout
    • Since content (text) is accessible, separating the formatting elements removes inaccessible barriers
    • Provides the additional benefit of easier content revision
  • Use remote style sheets since browsers & assistive technology might display the local styling in-line, or at the top of the rendered page
  • Ensure the page is readable without the use of the style sheet

Flash

Forms

Typically, web-based forms are not easy for a person with a disability to complete. Complicated navigation and ambiguous instructions can create a frustrating experience.


Guideline (n): When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.

(...more to follow...)

Frames

Java

''To develop accessible code, only use the Java Foundation Classes/Swing Set (version 1.8 or newer) and:
  • Ensure event handlers are structured so they are input device-independent
  • Set accessible descriptions for all components, particularly icons & graphics
  • Set the focus
  • Label components
  • Name logical groups
  • Be sufficiently multithreaded
  • Provide a logical layout

JavaScript

While very handy & powerful, JavaScript does have limitations, particularly when it comes to accessibility. The following details common event handlers & commonly accepted practices when using JavaScript, with accessibility in mind.
  • When using JavaScript links in conjunction with a graphic to invoke a function (i.e. href="javascript: function()"), use the ALT attribute, not TITLE.
  • Test your event handlers using assistive technology. These have been found to work:
    • onClick
    • onLoad
    • onUnload
  • Use caution with these event handlers:
    • onMouseover
    • onMouseOut
    • onBlur
    • onFocus
  • Avoid these event handlers:
    • onDblClick
    • onMouseDown
    • onMouseUp
    • onChange

Multimedia

Navigation

Image maps are ok to use as a navigational tool provided developers incorporate a few simple coding techniques to make navigation fully accessible.


Guideline (e): Redundant text links shall be provided for each active region of a server-side image map.

Guideline (f): Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape.

Guideline (o): A method shall be provided that permits users to skip repetitive navigation links.

  • Use client-side image maps whenever possible
    • Provide adequate text descriptions by using an ALT attribute with each AREA tag
    • When you cannot define the regions properly, use a server-side image map and provide redundant text links
  • Allow users to skip repetitive navigation menus/links
    • Sight-dependent users can visually "jump" to refreshed or main page content; visually-impaired users rely on screen readers that start in the upper-left-hand corner of every page
    • The ALT text for a 1-pixel transparent GIF can serve as a "signpost" before a complex page element


Although not dictated by section 508, these techniques will provide a better user experience and increase the accessibility of a page.

Intuitive navigation is essential to keep users oriented. Provide cues as to where the user is, where they should go, how to get there, and how to get back.

  • Other non-508 specific techniques:
    • Create an interface & navigation scheme that is intuitive and consistent
      • Place reusable elements in a consistent location
      • Place navigation at top and bottom of pages
    • Create a logical tab order for the page with TABINDEX.
    • Create a keyboard shortcuts with ACCESSKEY (i.e. Alt-P)

Non-text Elements

Guideline (a): A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content).


By not providing textual representations of non-text elements you may be unintentionally blocking sight-impaired users from important content. It’s also important to be sensitive to what a user will hear when using a screen reader. Listening to the contents of a web page can be challenging enough without having to sort through auditory garbage.

  • Provide meaningful alternate text descriptions (ALT text) for all graphics, image maps, spacers, bullets, and applets
    • Limit the length of ALT text – many browsers render ALT text without word wrapping, so long text can result in a page that exceeds the width of sighted readers' displays
    • For spacer gifs & other images unrelated to page content, use a hyphen ("-")
    • For graphical bullets, use an asterisk ("*")
    • When embedding an element with the OBJECT tag, provide both ALT and TITLE attributes
  • For detailed descriptions, use the LONGDESC attribute; if your target platform doesn't support LONGDESC, consider:
    • A hyperlinked "D" that links to a description page
    • A 1-pixel transparent GIF with ALT text linking to a page with a detailed description. While invisible to sight-dependent viewers, screen readers will be able to read the hyperlink perfectly.
  • Other non-508 specific techniques:
    • Don't put content-relative text within a graphic (can't be enlarged with magnification)
    • Avoid ASCII art (gibberish to screen readers)

PDF

Adobe PDF files preserve the formatting and text layout perfectly for sight-dependent users. Users can download a utility from http://access.adobe.com to convert the file to make it accessible to screen readers. As of April 18, 2000, Adobe partnered with Microsoft, GW Micro and Henter-Joyce to support the Microsoft Active Accessibility (MSAA) Application Programming Interface (API). Note: Avoid creating PDF files as graphical images

Plug-ins

Scripts

Guideline (j): Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.


Guideline (l): When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.

Guideline (p): When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.

  • Users can disable scripts
  • Assistive technology often does not fully support JavaScript and other client-side scripting
    • JavaScript is mostly used for events triggered by a mouse; assistive technology users generally don't use a mouse
    • Screen readers can't read moving text
    • Avoid pop-up windows and auto-refresh - both can disorient a visually impaired user
  • Server-side scripts may slow down the Web server, but all pages seen by the user are HTML (which can be interpreted by assistive technology, if accessible)
  • Allow the user to initiate change
    • If a timed response is required, provide a method for the user to request additional time or provide an alternative version
    • Provide speed and/or replay controls to allow users to repeat a moving image or text
  • Other non-508 specific techniques:
    • Provide a NOSCRIPT element in case a user's browser does not handle scripts
    • Create accessible script output or provide an alternative format for the content
    • Don't write script that cause a user's screen to flicker (moving text or graphics)

Tables

It is very important to separate the structure of a page's content (information flow) from the presentation (layout). HTML was not designed to handle complex layouts and older assistive technology devices may have difficulty interpreting it. Until CSS is better supported, developers will still need to use tables for complex formatting.


Guideline (g): Row and column headers shall be identified for data tables.

Guideline (h): Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.

  • Provide row and column headers for all data tables
    • Use SCOPE for header cells in each row and column
    • Use TH for header cells and TD for data cells
  • When using a complex table structure:
    • Use the SCOPE attribute; can be used with COLSPAN to include multiple levels of headers (headers will be read in order when the screen reader reaches the data cell)


Alternatively, the ID attribute can be used in every cell in a header row or column. Then place the HEADER attribute in every data cell to associate the data cell with the header cell(s).

This technique is much more cumbersome than SCOPE.

    • Group rows with THEAD, TFOOT, TBODY
    • Group columns with COL, COLGROUP
  • Other non-508 specific techniques:

If you use a table for layout:

    • Indicate in the table’s attributes that it’s not used for data
    • Don't use structural markup reserved for data tables (i.e. TH)
    • Ensure that information in the table is readable when linearized: read left to right, right to left & top to bottom
    • Provide alternate descriptions for complex tables and graphs
    • Use relative (%) sizes to minimize confusion if a user employs a screen enlarger
    • The SUMMARY attribute is often suggested, but is not widely supported by assistive technology yet

Development Tools

Editors

  • BBEdit (BareBones Software)
    • Macinstosh only
    • Automatically adds a blank ALT attribute to every image and AREA of an image map; serves as a visual prompt
    • Customize keyboard shortcuts to menu commands
  • HomeSite and ColdFusion
    • Windows only
    • Provides accessible drop-down menus
    • Automatically adds a blank ALT attribute to all images
    • Validation tools including customizable tag inspector

WYSIWYG

Visual (WYSIWYG) HTML editors offer conveniences unavailable in text editors. Typically, WYSIWYG software is used for formatting (layout) rather than structure (content).


Each of the following tools list accessibility innovations and concerns:

  • Mozilla Composer
    • Easy to use and available for many platforms
    • Can easily create accessible Web pages
    • Can't use the keyboard to select some types of content
  • Microsoft FrontPage
    • Accessibility needs are included in the packaged "themes"
    • The rollover image Java applet is inaccessible
  • Macromedia Dreamweaver
    • Built-in accessibility checker
    • Easy to insert ALT text and table headers
    • dHTML is not typically accessible
  • SoftQuad Software's HoTMetaL PRO
    • Embedded accessibility features (part of their AdaptAble Technologies) include a built-in accessibility validator and an on-screen keyboard
    • Provides convenient input of ALT and LONGDESC attributes

Validation

Testing Tiki

Colors

Colors can have a tremendous impact on not only how we perceive information, but it can also impact our ability to access information. The following are recommendations for how to experience Tikiwiki from the perspective of a person that has difficulty with colors & certain color combinations.
  • Surf Tiki on a monitor set to various color specifications (particularly black & white). Do you experience any problematic areas?
  • Print the page on a black & white printer
  • Use high contrast to ensure the page is readable

Format

Test the format by changing the following browser options:
  • Disable all images – is there ALT text for every image?
    • Does the ALT text give you a good idea of what the image represents?
  • Disable style sheets to ensure the page is readable
  • Set the font size to its maximum to ensure no content is lost
    • If content is lost, report it to the AccessibilityTeam & help figure out what’s causing it (look at the divs in particular)
  • Resize the browser (larger and smaller) to ensure no content is lost
    • If content is lost/becomes inaccessible, report it to the AccessibilityTeam & help brainstorm on how to fix it


Also test the format by doing the following:

  • Account for different sizes & types of monitors
  • Select all text and copy it into a word processor – does it still make sense? (This is probably how an assistive technology device will read your page)

Media

How do you process information most effectively? Visually, auditorily, kinesthetically, or some other way? What if you have trouble hearing, or are completely deaf? It's important to ensure people aren't left unable to use Tikiwiki because of hearing loss. Below are some suggestions for what to consider in trying to simulate experiencing Tikiwiki as if hard of hearing, or deaf.
  • Mute all sound. Is any information lost (i.e. instructions, dialog in movies, etc.)?
  • Is closed captioning available?
  • Is the software required to play the media free? What is that software's 508-compliance level? Does it support all the accessibility features used in the media?
  • Does Tiki have a link near applicable media to download the latest recommended playback software?
  • Disable all applets & scripts. Can you still access all content?

Navigation

  • Navigate the entire site using only the keyboard
    • Can you get to all the information on the site?
  • Using your Tab key, move through the links & form fields. Can you activate all of them?
    • Are the links, form fields, etc in a logical tab order? (tab order is the sequence of where the cursor moves from one object to another)
    • Imagine you couldn’t use a mouse. Is it easy to move around Tiki?
  • Is it clear when & where content has changed when clicking a link?
    • Imagine you’re blind. Is it still as clear?
  • Does link text by itself tell you where it will take you? (i.e. does it say, "UserPagemusus" or just "click here"?)
  • Does every link have a TITLE or LONGDESC attribute (as detailed earlier) that provides clear, and concise information on where the link will take you?

Additional Tests

Resources

Toolkit

A-Prompt Toolkit for HTML Editors
  • Works embedded within an HTML editor or standalone
  • Uses 22 accessibility guidelines from the W3C Web Accessibility Initiative (WAI) to conduct validation tests and repair
  • Prompts user for accessibility HTML code enhancements

References

Validators

Layout Analyzers

Filters

Tips for Coders

Who works here?

Discussion/participation

Created by: Last Modification: Tuesday 08 March 2005 12:07:55 GMT-0000 by Michael Davey
List Slides