At last week's workshop on Institutional Web Management there was a
session on Institutional Web Design which included discussion on preparing a
design brief. There was also a talk from Paul Booth from the DISinHE Centre
(see http://www.disinhe.ac.uk/) on accessibility and the web which attracted
a lot of interest.
Those of you who are interested in design briefs and accessibility may be
interested in the following message.
Thanks
Brian
------------------------------------------------------
Brian Kelly, UK Web Focus
UKOLN, University of Bath, BATH, England, BA2 7AY
Email: [log in to unmask] URL: http://www.ukoln.ac.uk/
Homepage: http://www.ukoln.ac.uk/ukoln/staff/b.kelly.html
Phone: 01225 323943 FAX: 01225 826838
-----Original Message-----
From: Eileen Bonfiglio <[log in to unmask]>
To: Robert Neff <[log in to unmask]>; [log in to unmask]
<[log in to unmask]>
Cc: 'Al Gilman' <[log in to unmask]>
Date: Tuesday, September 22, 1998 7:52 PM
Subject: Re: WAI and govt contracts
>Perhaps, large Gov't agencies will suffer these maladies, you are correct.
>Maybe, it is time for the local Gov't agencies to step up to the plate and
>lead the way. I am an Internet Specialist/Program Manager/WebMaster (and a
>few other titles yet to be discovered I am sure) for a growing City in
>Florida and that is what I have done. We contracted our site to be built
>for us in the interest of time, our contract scope/statement of work reads
>something like this:
>
>3.9.3. Images and Image Maps
>3.9.3.1. All images and image maps have alternative text.
>3.9.3.2. Graphics that present important information (especially charts,
>tables, and diagrams) have an associated longer description of the graphic
>(i.e., via a description link or the "longdesc" attribute) Furthermore,
>authors have included internal text in images for formats that support it.
>3.9.3.3. All image maps are accessible and keyboard navigable.
Furthermore:
>For each client-side image map, each of the map's links has an associated
>description. For each server-side image map, lists of the maps links are
>provided as text links (on the same page, on an alternative page that is
>accessible, or within the body of the OBJECT element).
>3.9.3.4. Images used as links have descriptive link titles.
>
>3.9.4. Applets & Scripts
>3.9.4.1. Alternative presentations (text files, etc.) of content are
>provided for applets and scripts that convey information.
>3.9.4.2. Alternative mechanisms are provided for applets and scripts that
>perform an important function (other than the presentation of information).
>3.9.4.3. All Applets that require user interaction that cannot be
duplicated
>in an alternative format are to be directly accessible.
>3.9.4.4. The user can freeze any moving or blinking text.
>3.9.4.5. Applets have alternative text ("alt" on APPLET, "title" on
OBJECT).
>
>3.9.5. Audio & Video
>3.9.5.1. All audio information has an associated transcript.
>3.9.5.2. All video information has an associated audio description.
>3.9.5.3. All video information has an associated transcript.
>3.9.5.4. Transcripts and audio descriptions are synchronized with
>audio/video information, either directly or via a synchronization file.
>3.9.5.5. Sounds that play automatically have a visual notification that the
>sound is playing.
>
>3.9.6. Tables
>3.9.6.1. Table cells are explicitly associated with row and column labels.
>3.9.6.2. Lengthy row and column labels are abbreviated.
>3.9.6.3. Tables used to arrange text documents in columns shall have a
>summary (as all tables will) describing contents.
>3.9.6.4. For more complex tables, information is grouped into categories.
>3.9.6.5. Table summaries are available, nested in the <table> tag.
>3.9.6.6. Phone number (xxx) xxx-xxx and/or e-mail address (webmaster@ my
>city) will be provided if tables can not be made accessible.
>
>3.9.7. Links
>3.9.7.1. Link text makes sense when read out of context, but is not too
>verbose.
>3.9.7.2. Lists of links have non-link, printable characters (surrounded by
>spaces) between them.
>
>3.9.8. Frames
>3.9.8.1. Each frame document (the FRAMESET element) has a non-frame
>alternative (e.g., the NOFRAME element)
>3.9.8.2. An image does not appear directly in a frame but is part of a
>document included in a frame.
>3.9.8.3. All frames have titles.
>3.9.8.4. Links to descriptions of the purpose and layout of frames are
>provided.
>3.9.9. User Input Forms
>3.9.9.1. Image maps are not used to create graphical "submit" buttons.
>3.9.9.2. Each label is associated with its form control.
>3.9.9.3. Images used as "submit" buttons have alternative text.
>3.9.9.4. An alternative phone number, fax number, e-mail address, or postal
>mail address is provided for submitting information.
>3.9.9.5. Form elements have keyboard shortcuts (with the "accesskey"
>attribute).
>3.9.9.6. Menu options are grouped (with the OPTGROUP element).
>3.9.9.7. Groups of controls are labeled (with the LEGEND element).
>3.9.9.8. Related controls are grouped (with the FIELDSET element).
>3.9.9.9. A logical tab order is specified (with the "tabindex" attribute).
>
>3.9.10. Site shall have a consistent look and feel and be representative
>of the City of <snip>.
>3.9.11. Site shall be non-browser specific.
>3.9.12. Site shall also comply with HTML 4.0 Specification, W3C
>Recommendation, revised on 24-Apr-1998 and be able to attain approval from
>CAST for accessibility.
>3.9.13. Do not use non-html technologies to display text unless an
>accessible version of the page(s) is provided as well. (I.e. PDF).
>3.9.14. If "OBJECT" is used to embed any components, provide description
>within the "title" of the element, since "OBJECT" does not have "alt."
>3.9.15. Avoid blinking or updating of the screen, which can cause flicker
>between 4 and 59 hertz.
>3.9.16. Ensure that pages using newer technology will fail gracefully if
the
>technology is not supported or is turned off. This includes frames,
scripts,
>style sheets and applets, and other new or proprietary features. Make
>information redundant as necessary.
>3.9.17. Provide a site map in plain text as well as HTML format.
>3.9.18. Style sheets should be used to control layout and presentation
>wherever possible, however, tables are permitted providing requirement
>3.9.6. is met.
>3.9.19. Accommodate older browsers with information and instructions on how
>to upgrade the browser in both plain text and HTML clear format.
>3.9.20. Browser detection scripting tools shall be used on all scripted
>pages.
>
><snip> You get the idea. The contractors are now embroiled in a learning
>process I don't think they would have embarked upon otherwise. I know this
>is small, but - we have to start somewhere.
>
>Happy to take a bite :))
>
>-Eileen
>
>
>-----Original Message-----
>From: Robert Neff <[log in to unmask]>
>To: [log in to unmask] <[log in to unmask]>
>Cc: 'Al Gilman' <[log in to unmask]>
>Date: Wednesday, September 02, 1998 2:09 PM
>Subject: RE: WAI and govt contracts
>
>
>>>From Chris Hasser
>>
>>A final note: I.M.H.O., your comment about contracting officers was not
>>quite complete. When a contracting officer writes a statement of work,
>>technical details are often supplied by someone more closely involved in
>>the
>>area in question.
>>Rob> True, and the procurement office will ask for the standards and
>>references. Could the WAI come up with a policy and reference list. I
>>know, lets ask Al Gilman! Al, what do you think?
>>
>>So efforts to educate government technology officers
>>would not be in vain. You might consider targeting the chief information
>>officer for each cabinet department for a letter from the WAI.
>>Rob> Good idea, but most CIOs do not have much authority. The position
is
>>still a paper tiger when it comes to agency policy and standards. Whether
>>or not this changes, it is still a good idea to send a letter from the
WAI.
>> It is a start or a foot in the door. This should also be sent to the
>>Procurements and Contracts Office for each Agency. How do we make this an
>>action item? If the Feds require this on a soliticitaion, the IT
>>Contractors will respond and perform to the Statement of Work.
>>
>>Rob> Chris, please keep us posted on the conference in October.
>>
>>Thanks..rob
>>
>>
>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
