Customer Concerns

People who are blind or visually impaired often call our agency for help with government Web sites that are problematic for them.  Problems include both 508 violations and usability issues.  In a few cases, issues may relate to lack of skills on part of the user.

Everyone Needs to Help

While many issues are code related, a lot of problems are content issues.  Process owners (the staff responsible for writing the content),  web developers, and graphic staff all play important roles in ensuring equal access for all.

For example, lack of a clearly defined descriptive label for a graphic of a chart becomes a coding issue, but the content belongs to the process owner.  The chart may have even been created from an accessible excel file by graphic staff.

All staff involved in the process of creating a document that is on a Web site needs to understand accessibility and usability issues.

Key Issues

While we get many complaints, including using color as the only mean of information or that text won't enlarge in browsers (IE6), the following four are the most common.  Issues overlap.

PDF files

PDF files are frustrating for persons who are blind or visually impaired.  It isn't because PDF files are bad, but rather because few are developed with these users in mind.  The most common problems with PDF files are listed below.

  • Many PDF files are scanned as images.
  • Many PDF files if scanned as text are not accessible even if they are tagged properly.
  • Column format is difficult to use with magnification.
  • PDF files are normally the ONLY format for a downloadable form or manual even when they are to printed out.

Solution:  Provide an alternative format such as the original word doc (in rtf or provide link to word viewer) or html page.

Poor site navigation

We all will agree that users need to be able to find information quickly and easily.  Many state Web sites visually appear to provide good site navigation.  But people with disabilities who use assistive technology are using the html code.  Few sites provide the same logical grouping of navigation in code that one might visually see.  This problem is made worst when navigation links are poorly defined (e.g. learn more).

Solution: Divide menu items using header levels and ordered or unordered lists.  Styles sheets can be applied.  Header levels can even be hidden.  Ensure that link descriptions are concise but descriptive.

Forms

When it comes to government, forms are a necessary tool to receive services or job opportunities.  Yet many customers are having difficulties using forms on government sites.  This problem relates to both downloadable forms and web forms.

PDF or Downloadable Other Forms

The major issue related to downloadable forms is that process owners and developers are thinking in terms of PRINT.  Users are supposed to print out the form, fill it in, sign it, and then send it.

But the users, especially persons with disabilities, may need a different process.  Fill out the form, print it, sign it and send it in.

Solution: Provide forms in alternative formats.  If the form requires instructions to understand it, make two files: an instructions file and a form file.  Speech users must get into edit mode to complete a form.  The form should not need a person to get in and out of the edit mode.

A great form example - instructions and forms separate with various formats - is located at http://www.irs.gov/formspubs/lists/0,,id=97817,00.html

Web Forms

Almost every case of lack of access or difficulty with a web form is a coding error.  The problem often is easy to fix.  But process owners can help with this issue.

For example, a login field is a web form.  Often process owners creates to more than one login field on one page and call them both login so the web developer does the same.  A user of speech hears login, login.  There is no clear indicator of what is being log into.

Or a process owner wants a page to look like a print document or an edit field.  The web developer tries to comply and finds it easier to use codes for fields for display purposes.  People with cognitive disabilities who have been taught to use the web using standard display information may try and be confused that they can't type into a field that looks editable.  People using assistive technology may think the field is real field rather than a display field.

Solution: Web developers must follow html standards for developing forms including non-duplicative descriptive "for label".  For continuous forms (more than one), ensure skip navigation to ensure speech users have the same access as sited folks to just continue with input of the form..  Process owners should become familiar with standard web forms and write content that is easier for developers to code.

Lack of clear descriptive "labels"

Developers often do their best to provide labels for such items as pictures, charts, text boxes, navigation tool bars, links and form fields. But the lack of clear descriptive labels is something that every process owner needs to be concerned with.  Web developers do not know the content like a process owner does.  A developer might label an important graphic with only two words, which will pass a validation program, but not do justice to the content.  Or the developer might attempt to describe a chart and incorrectly describe the data.

Solution:  Develop a system where process owners are responsible for providing an alt tag, a long description and/or a d link page.  Train process owners of the need for descriptive labels for items like navigation bars, links, graphics, or charts.