Commentary on Illinois Web Accessibility Standards (IWAS)

1. Coding

1.1 Use valid, standard web programming code.

Yes

Difficult. And probably not worth the effort. It would be better to put energy into using validated code, structural models, and style sheets on new pages. The exception would be if an automatic templating system was used.

Fairly easy. Pick a TLD, and stick with it.

The abject lack of web standards compliance demonstrated by Microsoft Internet Explorer poses a problem here. Following the standards may produce bad results for Explorer.

1.2 Use appropriate markup to convey document structure.

Yes

See above

Fairly easy, and can help with conversion to a CSS-based design as well.

1.3 Use style sheets for formatting whenever possible.

No

See above

CSS isn’t nearly as simple as some might have you think, but the benefits for accessibility and site management are massive, and probably worth it.

2. Text

2.1 Avoid using images to display text.

No

Moderate: Would require some reworking, but the benefit of easily read text which will almost always load.

Easy: the text would be simpler to present.

My yes is a moderate one: I feel that if the text is essential information (i.e. not a heading or logo) then by having the text not embedded in an image opens up accessibility to more browsers and OS’s.

2.2 Avoid using absolute sizes for fonts.

No

Moderately difficult: sites which already use them would require a lot of recoding. Sites with many of these encodings might result from authoring tools, too, and those are tough to control.

Easy: just use relative sizes, or style sheets, which allow percentages.

This is very useful not only for folks with vision problems, but for dealing with computers with small screen sizes.

2.3 Specify the language of text.

Yes

Fairly easy.

Easy.

Indicating the language used is a matter of adding the attribute lang="en" to the HTML tag. If a site template is used, this change is trivial for new sites.

2.4 Avoid using “ASCII art.”

No

ASCII art is likely rare; this seems reasonable.

3. Colors

3.1 Do not convey information with color alone.

Yes

Moderate: but should be required to help those with poor eyesight.

Easy.

To best serve not only color blind, but people with eyesight problems this is a must. Also, it is just good design. It does imply that not underlining links, which seems hip, is a bit problematic.

3.2 Use contrasting foreground and background colors.

Yes

See above

See above

See above

4. Images

4.1 Provide “alternate text” for all images.

Yes

Fairly Easy: Should not require much redesign, just a new link and text description

Easy

This is a good practice to allow people with lesser browsers and older OS’s to have access to the information. Most web authoring software makes adding this text quite simple.

4.2 Provide full descriptions for graphs, diagrams, and other meaningful images.

Yes

See above

See above

See above

5. Image Maps

5.1 Provide alternate text for each area in client-side image maps.

Yes

Fairly easy.

Easy.

See above notes on alternative text for images.

5.2 Avoid using server-side image maps.

Yes

Easy. Client-side maps are much less of a pain than server side.

Easy. Implemented by common software.

Does anyone use server-side image maps any more?

6. Audio

6.1 Do not convey information with sound alone.

Yes

Moderate to Easy: I have not seen any official site with much sound conveying information. (Hrm, what about distance education with audio?)

Easy

This is also good practice to assist the hard of hearing, people either without a proper soundcard, or those in a situation where they cannot use their speakers (quiet office or library).

6.2 Provide text transcripts for audio containing speech.

Yes

Possibly Difficult: I do not know of any official sites with major video presentations, but for those who do it will be time consuming to transcribe. (WIU athletics?)

Moderate: Time is also an issue for the transcription of the audio.

See above

7. Multimedia

7.1 Provide synchronized captions for multimedia containing speech.

Yes

Difficult: And I am not sure how practical a retrofit would be. Captioning might have to be added at the point of creation.

Moderate: It would add a step to the creation of multimedia, but an important step to take to reach a wide audience.

See comment for 6.1 above

7.2 Provide audio descriptions for multimedia with significant video.

Yes

See above

See above

In television captioning, this is part of the captions, so I see it as part of 7.1 not a separate category.

8. Animation

8.1 Avoid flickering, blinking, and unnecessary animation.

No

Fairly easy.

Easy.

Since flickering animation can cause serious problems, avoiding it is a darned good idea. It’s often quite annoying...

9. Links

9.1 Make sure that links are understandable out of context.

Yes

Difficult. Can require heavy editing.

Fairly easy.

Requires careful writing and/or usability testing to ensure the assumed context is developed properly.

9.2 Provide a means of skipping past repetitive navigation links.

Yes

This is important for a user-friendly web page.

9.3 Avoid using small images or text as links.

No

Easy. It’s not a mandate, so small text could still be used for some links (relatively sized, of course—see 2.2 above).

Generally speaking, this is bad design practice regardless of accessibility issues.

10. Forms

10.1 Associate labels with all form fields.

Yes

We need more research here—how difficult is it to achieve these mandates?

10.2 Position labels as close as possible to form fields.

Yes

10.3 Include any special instructions within field labels.

Yes

10.4 Make sure that form fields are in a logical tab order.

Yes

11. Data Tables

11.1 For simple data tables, explicitly identify headings for all columns and rows.

Yes

Moderately difficult. Can require a lot of recoding and/or reformatting.

Easy.

Generally speaking, this is just good table design (c. f. Tufte).

11.2 Avoid using complex data tables.

No

It’s often possible to replace a single complex table with two less difficult ones. But the point of one big table can be the relationships it establishes...

12. Frames

12.1 Provide meaningful names and page titles for all frames.

Yes

This is important for a user-friendly web page.

12.2 Avoid using empty or non-essential frames.

No

Fairly easy. The frameset can be removed, and the content within frames displayed on its own.

Easy. Frames are not a part of most new designs.

Again, a case where design best practices and accessibility are parallel.

13. Scripts

13.1 Make sure that significant interactions can be performed with both keyboard and mouse.

Yes

We need more info here. Many WIU sites using JavaScript may do so in violation of the IWAS.

13.2 Make sure that essential content and functionality are available when client-side scripts are not fully supported.

Yes

14. Applets and Plug-Ins

14.1 Use accessible applets or plug-ins whenever possible.

No

We need more info on just what this means.

14.2 If an inaccessible applet or plug-in must be used, provide an accessible alternative that includes the same content and functionality.

Yes

15. Downloadable Documents

15.1 Provide accessible HTML or text versions of downloadable documents whenever possible.

No

Difficult: With time documents change and the alternative could be added when making needed changes anyway.

Easy: Just another link and setting up the alternative format.

No real need to retrofit, just require for new documents and whenever a document is reworked. BUT: see 19.1 below, which implies that this separation is a Bad Thing.

15.2 If a downloadable document cannot be provided in an accessible format, provide information on how to request an alternate format..

Yes

Easy: Simply adding contact information

Easy: Add contact information to each document area.

Essential if one does not implement 15.1, so that anyone viewing the site can obtain the information, no matter what.

16. Window Control

16.1 Notify users of actions that will open a new window.

Yes

Generally speaking, one should let the user decide if she wants to open a new window.

16.2 Do not automatically refresh the current page.

Yes

Again, one of the places where good design and accessibility are congruent.

16.3 Notify users of time limits and provide a means to extend time if needed.

Yes

This seems to affect a minimum of WIU pages—for testing only? In that case, infrastructure should already be in place to help with those who need extra time. Perhaps more research is needed.

17. Page Layout

17.1 When using tables for layout, make sure that reading order is logical.

Yes

Difficult, and not worth it. Any effort spent on modifying tables for layout would be better spent creating a design which didn’t use them.

Moderately difficult. CSS positioning is the best alternative to table-based layout, but it is just now becoming supported by how-to books and software.

Tables for layout need to go away, but it will likely be a while before they do. This is a case where providing tutorials and models would really help the WIU community.

17.2 When using style sheets for layout, make sure that reading order is logical when style sheets are not supported.

Yes

See above

See above

See above

17.3 Minimize the need for horizontal scrolling.

No

Moderate: Would require some reworking of pages, but the benefit is in the easy presentation of the material.

Easy: Start from that point in design.

For ease of the viewer/reader the need to scroll horizontally is disruptive and not natural. To have an easy to follow design, it is best to keep the viewer/reader moving in one direction. Think how difficult it would be to read a sentence is it went left and right.

18. Page Content

18.1 Use the clearest, simplest, and most concise language appropriate for a page’s subject matter.

Yes

Moderate difficulty, but good benefit: It would require some rewriting, but for the most part it would enhance the readability of the websites. However, would such effort be better spent elsewhere (e.g. new designs)?

Moderate difficulty: It is very hard to find the easiest way to say something. It is difficult to find the easiest way to say something. Finding the easiest way to say something is difficult. (OK, point made.)

Simple never means dumb; it just means simple.

19. Alternate Accessible Versions

19.1 Use separate accessible versions only as a last resort.

No

Difficult. Eliminating separate accessible versions could require extensive redesigns.

Hopefully easy. If the suggestions in these standards are followed—especially sections 1 through 4—accessibility will be good or excellent.

While this may seem problematic, the reasons stated in the standards are good. Alternate versions are like “separate but equal”—they are often not updated and rarely equivalent.

20. Contact Information

20.1 Provide contact information.

Yes

Easy, and necessary to allow the viewer/reader more information. Provides strong benefit.

See comment at left.

The websites this applies to are mainly for marketing or class work, so contact information is vital. I can think of few cases where not providing contact information is a good idea.

21. Testing

21.1 Test for accessibility.

Yes

Maybe. Testing is only a good idea if it would be used to generate changes or in new site development.

Fairly easy. Testing can take time, but is worth it; Steve Krug and others have shown that it need not be costly to be effective.

Can WIU fund purchase of local testing software? Or installation of free testing software? Even so: automated testing only works so well. Where can we find a pool of testers?