Accessibility in Documentation
With computers and content reaching everywhere and everyone, we need to make sure that that public content is accessible to the public. This means equally accessible to the disabled.

Page Contents Registered members can join this collaboration or post a comment.

Return to the list of Key Collaborations.

While the State of Florida has promoted the 508 Web initiative, and worked to improve facility and voter registration accessibility, it has done little to improve the accessibility and usability of technical documents that the physically, developmentally, and socially challenged must complete to apply for state assistance. Bureaucratic rhetoric, confusing and misleading language, and poor document design permeate these documents. Many potential clients who are developmentally challenged or who have limited language skills abandon the effort altogether; others repeatedly apply incorrectly only to be denied services and without any reasonable explanation (so the problem cannot be corrected). In one example, a waiver is completed to apply for medical health coverage assistance. For most readers, waiver means to give up a right to something. In this case, to fill out a waiver means to apply for health coverage. The same application gives no indication of its real intent. Readers must dredge through pages of text-only forms before filling in any information. By then, potential clients are confused and often give the incorrect information, which results in denial of services.

In areas where incorrect or misleading information can cause costly losses, personal injury, or even loss of life, we are obligated to ensure that the technical information we develop is correct and usable. But this obligation should not be limited to documents about technology. As technical communicators, we have an ethical obligation to act as user advocates for those cannot act for themselves when we are the creators of public documents.

Background

For a start, you can see what we mean by Accessibility by reading some of the content on these sites:

The big software players are getting into it. Companies, such as
Adobe, IBM, Macromedia, Microsoft, Oracle and Sun.


Access Keys

In order to make KeyContent.org (and other sites) accessible, access keys can be used to let users easily and quickly move to other parts of the site. There does not appear to be anything in WAI or Section 508 that specifies standards for access keys. One (potential) problem is that many browsers reserve specific keys for their own use.
  • Do you want to use Alt+A to go to your About page? Sorry, that key combination is commonly used for "Favorites" functionality.
  • Do you want to use Alt+H to go to your Home page? Sorry, that key combination is used for "Help"

So the question becomes, what should be used? There's a nice analysis on clagnut.com which looks at the "standard" (or lack of) access keys.

Here are the access keys used on KeyContent.org:

Key Page
S Skip navigation links
1 Home
2 Key Collaborations
3 Contact Us
4 About KeyContent.org
5 KeyContent RSS Feeds
6 Chief Editor's Blog
8 Login Username
9 Login Password
0 Site Search


Adding Access Key Support

To add access key support to a specific link or function in your page, use the accesskey attribute in your <a href...> anchor.

For example, the Alt+1 access key (return to home page) used in KeyContent.org was created with:
<a accesskey="s" href="index.php">......</a>

Self-labeled Forms

The WAI states that, as a priority 2, form controls must be explicitly labeled (See checkpoint 12.4.)

Normally, this means using the <label for="..."> for each element in a form.

<form name="sample">
<p><label for="username">Username</label>:
<input name="username" id="username" type="text" />
</form>
Sample form showing LABELs


However, there is an alternative — making a self-labeled form. In this example, the input field is explictly identified and "labled" without using the <label> element. Instead we've given the field a default value.

<form name="sample">
<input name="username" id="username" type="text" value="Username" />
</form>
Sample form showing self-labeled area.


This method has several benefits:
  • Less HTML means smaller page size
  • Requires less UI space
...and some problems:
  • Requires additional form validation — you don't want users to submit the form with the default text.





{SUBMIT()}{SUBMIT}






Contributors to this page: Rick Sapir , editor , Bill Albing and KeyContent.org Webmaster .
Page last modified on Wednesday, July 27, 2005 06:53:41 pm EDT by Rick Sapir.

Key Pick New

Bill Albing has some suggestions to improve STC competitions. Read and let us know, what do you think?

Other Key Picks... Read more

About KeyContent

About KeyContent
KeyContent.org is an idea space where you can express your insights about your profession. Think of this site as a white board with a brain. You create and edit articles or portals to other sites and share your insights... Read More


Key Ads

Key Connections

Join KeyContent on these networks:



Key Products

Make Custom Gifts at CafePress

Key Promotions