Gary Perlman
http://www.acm.org/~perlman/
The Web is everywhere, but can everyone access your service?
This question will be addressed at a
SIG session at CHI 99.
Some barriers to universal access:
At OCLC, I am working on the next generation of the FirstSearch service,
with some focus on creating a system that is highly accessible
by being:
- intuitive to a broad range of user levels
- available in multiple languages
- accessible to persons with disabilities
- usable on a wide range of browser versions
The desire to design a maintainable system with these attributes
has motivated me to:
- Learn more about these areas, which in turn led to
the creation of most of the link pages available
from the SIGCHI and SIGCAPH sites (now some of
the most popular pages on those sites).
- Try to address all these concerns in a coordinated effort,
which in turn led to the evolution
of techniques for developing highly configurable systems.
Architecturally, the main feature is the separation of:
- Language:
All language terms and phrases in structured language files.
The structure divides language entities by type and where used.
- Display Style:
All display attributes in style files.
The style files centrally define the colors, fonts, a layout of elements
for different platforms.
- Functionality:
All definitions of parts of pages in a separate file.
The pages file defines the functional parts of pages
without defining the terminology used or the screen layout.
The user interface is configured based on runtime attributes:
-
Language:
from the HTTP 1.1 header, login preference, or runtime choice
-
JavaScript:
Availability of JavaScript 1.1
-
Browser Version:
from the HTTP 1.0 header MSIE 3.* 4.* 5.*, Mozilla 3.* 4.*, Lynx 2.3-2.7
-
Platform:
from the HTTP 1.0 Windows, Macintosh, other
-
Screen Size:
from login preference or JavaScript check
Based on these, entities in the Display Styles are adjusted
and pages are dynamically generated,
with entities being substituted on the server side
by SiteSearch.
Many promising technologies were avoided:
-
No Java Applets:
- required higher-end machines (economic barrier)
- not applicable to older/non-GUI browsers
-
No Cascading Style Sheets:
- too buggy on Netscape Navigator 4.0
- did not apply to older/non-GUI browsers
- we could define Display Styles using SiteSearch
-
No Java 1.1 Internationalization:
- duplicated technology already available with SiteSearch
Check out how Bobby runs on
http://www.hcibib.org/
(there is an accessibility check link at the bottom of each page).
But Bobby does not check for a lot of features supported by IE 4.0+
(and not at all by Netscape 4.5 :-().
At hcibib.org:
- Click on the Find: label - The focus is set on the input field
- Hover over the input field - popup help
- Alt-s starts the search
- Hover over the Featured Query - popup help
Click on Start Search to get to the search page
- Hover over the input field - popup help
- Hover over the example under the box - popup help
- Hover over the checkboxes for a longer description
- Click on the checkbox labels and the checkbox is un/checked
- Hover over the USAGE table
- Every link on the page has a title tag for popup help
Click on the ACM SIGCHI link in the upper right
- ALT text AND title text for each graphic links
- title text for most major links give longer explanations
- Hover over the subsection titles (GENERAL INFORMATION) - popup help
I'm not sure all of these are good ideas, but I like the opportunity
to add a little bit of help to each item.
IE provides some support for the table section tags
(better in IE 5.0 than 4.0). Some features do not
work as advertised in my O'Reilly HTML book,
but there are usually workarounds.
The features that work well on IE (Netscape supports none of these,
but at least it ignores them):
- LABEL tags associate labels with form elements
- FIELDSET tags identify sections of forms (redundant DIV tags help Netscape)
- ACCESSKEY attributes for common items (Alt-x activates item with accesskey=x attribute)
- TITLE attributes on items (even table cells and div tags) show popup help
and have a lot of potential
I've seen no support for the scope tags in tables (I had hoped to see
a big leap in IE 5.0 accessibility support, but I've only seen minor fixes).
Caveat: A screen reader may not use any of these features.
You need to actually try it, and may need to write scripts
for the application to work with a particular screen reader.
- Universal accessibility is usually hard, but there are benefits
(e.g., consistency, maintainability)
- Many compromises on which features to use
(CSS, Java, ...)
- Evaluate designs on critical platforms continuously
(Win/Mac, 640x480, 256 colors, 3.*/4.* IE/NN)
Even validated HTML may not look right.
- Use accessibility checks on screens:
http://www.cast.org/bobby/