The W3C and Accessibility section includes annotated links to W3C's accessibility guidelines, checklists, articles and tutorials, and related accessibility information at W3C's site.

Do you know of some good articles, tutorials, tips, Web sites, books, or other resources related to Web site accessibility or the W3C's? Web Accessibility Initiative? Recommendations are welcome and encouraged!

Windows




On Windows, registration is done by the OS. To change the OS's settings, create a .reg file, and place this in the file:





REGEDIT4

[HKEY_CLASSES_ROOT\foo]
@="URL:foo Protocol"
"URL Protocol"=""

[HKEY_CLASSES_ROOT\foo\shell]

[HKEY_CLASSES_ROOT\foo\shell\open]

[HKEY_CLASSES_ROOT\foo\shell\open\command]
@="\"C:\\Program Files\\Application\\program.exe\" \"%1\"" 




Replacing foo with the protocol you're specifying and C:\\Program Files\\Application\\program.exe with the program you want to run. Note that backslashes must be doubled and the additional slashes and quotes before the path must not be removed. Save the file, then double-click it to insert into the Windows registry.


See Registering an Application to a URL Protocol for additional information.




[edit]

Linux and Mac



• Type about:config into the address bar and press Enter.
  
• Right-click -> New -> Boolean -> Name: network.protocol-handler.external.foo -> Value -> true (Replacing foo with the protocol you're specifying)
  
• Right-click -> New -> String -> Name: network.protocol-handler.app.foo -> Value -> /path/to/app (Replacing foo with the protocol you're specifying and /path/to/app with the path to the application you want to run.
  
• Ensure network.protocol-handler.expose-all is set to true.

The following example shows which registry values might be added to register a new application (Notepad.exe in this example) to handle the new URL protocol.

HKEY_CLASSES_ROOT

note

(Default) = "URL:Note Protocol"

URL Protocol=
""

DefaultIcon

(Default) = "notepad.exe"

shell

open

command

(Default) = "C:\WINDOWS\notepad.exe" "%1"

One of the nice things about old-school table layout methods is that they enable you to create liquid page designs very easily. If you want to center content vertically or stick a footer to the bottom of the browser window, all you have to do is include one main table with a height of 100% and position elements inside of it.

With web standards, you can’t do this anymore. The table height property is deprecated in XHTML, and web standards recommend that you avoid using tables for page layout. To divide structural markup from presentation, CSS is the way to go — but if you want to use CSS for vertical positioning, you face a lack of support from some mainstream browsers.

This article explores the ways you can position footers using web standards, although the same techniques may be used to vertically position other elements. Many designs contain a footer that is positioned directly under the content area, unless the content and the footer together don’t fill the window entirely. In this case, the footer will be positioned at the bottom of the browser window.

The intention here is to compare the Priority 1 Web Content
Accessibility checkpoints with the Section 508 Web Accessibility standards.
However, some of the 508 standards relate to lower priority checkpoints
from the Web Accessibility Initiative. The view of the Web Content Accessibility
Guidelines lists only the priority one checkpoints The Section 508 view
includes priority 2 and 3 checkpoints in the comparison.

The first table lists the Priority 1 Web Content Accessibility
checkpoints followed by a comparison phrase like "the same," and then the relevant Section 508 web accessibility standard or standards. This
table is titled "The WCAG View."

The second table is titled, "The
508 View." It lists all the 508 standards, and for each one, the comparison phrase, and
the relevant WCAG checkpoint or checkpoints.

The following three short sections introduce the 508 standards,
and the WCAG priority 1 checkpoints and some resources.

About
JAWS

JAWS
for Windows is a powerful accessibility solution that reads information
on your screen using synthesized speech. JAWS provides many useful commands
that make it easier to use programs, edit documents, and read Web pages.
With a refreshable braille display, JAWS can also provide braille output
in addition to, or instead of, speech. An array of versatile features
and customizable options lets you tailor JAWS for your individual needs
and preferences.

Step-by-Step Usability Guide

Most common CSU Section 508 Website Repair needs





• Alt attributes for graphics/images


• Using Links


• Form Controls and Label elements
  
  
  
  • FIELDSET and LEGEND
  
  
  • LABEL Element
  
  
  • ACCESSKEY and TABINDEX
  
  
  
  


• Default, place-holding characters in edit boxes and text areas


• Alternative text for all image map hot-spots


• Data Tables


• Structural Markup


• <NOSCRIPT> tags

6. Web Content Accessibility Guidelines



• 1. Provide equivalent alternatives to auditory and visual content.
  
• 2. Don't rely on color alone.
  
• 3. Use markup and style sheets and do so properly.
  
• 4. Clarify natural language usage
  
• 5. Create tables that transform gracefully.
  
• 6. Ensure that pages featuring new technologies transform gracefully.
  
• 7. Ensure user control of time-sensitive content changes.
  
• 8. Ensure direct accessibility of embedded user interfaces.
  
• 9. Design for device-independence.
  
• 10. Use interim solutions.
  
• 11. Use W3C technologies and guidelines.
  
• 12. Provide context and orientation information.
  
• 13. Provide clear navigation mechanisms.
  
• 14. Ensure that documents are clear and simple.