E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 2 (In chronological order)

From: Terence de Giere
Date: Wed, May 28 2003 8:55AM
Subject: Re: priority ratings
No previous message | Next message →

Level Triple-A Accessibility Compliance versus Level Double-A, or worse.

There are ambiguities in applying the accessibility guidelines, and you
might find that if a number of different accessibility experts were to
make a judgement on certain features, you might find some disagreement
among them, especially with regard to accessibility problems that
software does not automatically tag for repair. There is variation in
the ability of the various accessibility checkers to assess problems, as
the software matures, the ability to automatically find problems tends
to increase. A number of factors, such as the site size, the complexity
of the page design, and the relationship between the pages may determine
whether implementing a certain accessibility feature should be used.

For example, take foreground versus background contrast. A page is
supposed to have sufficient contrast to pass an accessibility guideline.
But the exact criterion or criteria for this is not specified. Some
software checks the color coding of the page, and if it is not black
against white, then it flags an error. But some viewers may need a low
contrast image to see features clearly, and among normal users there are
many combinations of colors that provide good reading speed under test,
but which are definitely somewhat lower contrast than black and white.

For example, dark green text on a light beige background has been shown
to provide good reading. The Courier typeface, in black on a medium to
light gray background (the default colors in the old Netscape browsers
such as version 2.0) is also easy to read for most normal users. An
added complexity is how colors might appear to color blind individuals -
accessibility software that provides a grayscale rendering of a page
does not give the same effect as software that can accurately simulate
the various color blind responses to color and contrast.

Thus implementing a particular level of compliance is not a completely
straight forward process. For many sites, the software used, the
organization's development environment and collective skills, the
organization's organizational goals, and disagreements between the
organization's factions may all contribute to limit what might be done.
Automated tools have done well in getting sites somewhere in the Level A
compliance arena. Even here there are manual checks that are often
overlooked.

Level Double-A and Level Triple-A require a lot more work, and with a
large complex site, the resources to make the change may not be
available. The cost of implementing a higher level of compliance might
be absorbed with a content management system that automatically handles
updates to the site, once the basic structure is programmed into the
software and paid for at this stage, but such a level might not be
feasible for a smaller site where employees must manually update pages
and have to check them for compliance each time.

Experience is important. Web development and design is a never ending
process of learning. The first attempts at accessibility by a design and
development team are usually flawed. A team might have specifications
for Level Double-A compliance, and the first release of the site, for
all those various reasons that delay progress, may not even fully comply
with Level A.

Those of us who have had more practice still have the experience,
especially on this forum, of finding out things we never knew. As with
usability specialists, accessibility compliance might be implemented in
a number of different ways by accessibility specialists. Further,
accessibility understanding and development of guidelines is an ongoing
process of refinement. The Web Content Accessibility Guidelines, version
2.0 that the World Wide Web Consortium (W3C) is now working on, in its
draft state seems subjectively fuzzy and less precise to me than the
first set of guidelines we are using now, and seem to me more
technically understandable. Maybe I am not thinking clearly. The W3C
thinks the new organization and changes in the material is better.

There is also the problem of backward compatibility. This can be the
result of a particular technology not implementing web standards
incorrectly or partially. Scripting and Cascading Style Sheets create
many problems. Implementing standards may be a problem if the standards
are not followed by the browsers.

While now just a small percent of users on the web use really old
browsers, such as Netscape 4.x browsers, they may still be used in a
higher percentage of users in corporations, or government sites that
have not upgraded to something more recent. Certain accessibility
conventions and work arounds (null alternate text for trivial, format
only images would be an example) work with some browsers and cause
accessibility problems for others. One can complain that such browsers
should not be used, but for practical reasons a developer may need to
support a particular browser, for example, legacy web applications
written for a particular browser on a corporate intranet.

One company I worked on a project for wanted to standardize on Internet
Explorer, but needed to support some older pages that handled company
business developed when Netscape 4 was the most used browser, and
therefore the new intranet design had to at least display legibly in
Netscape 4, because that browser would be used until it could be phased
out at a later date than the new site design. The new design, developed
by usability specialists, basically needed to be retrofitted to Level A
accessibility compliance, and it was so complex, that from a usability
perspective, the site was not particularly good with assistive
technology. During development, the development team, using Lotus notes,
discovered that for certain page configurations they needed to use
frames. The new site specification and accessibility guidelines, however
were not developed for use with frames.

A lot of pages using complex CSS positioning display miserably in
illegibly on MSNTV (formerly WebTV). A television set top device with
the Opera browser built in would be more likely to succeed in displaying
such pages properly.

While accessibility and usability usually are strongly related, a
technically accessible page might be difficult to understand or navigate
from a usability point of view by disadvantaged users. Usability
questions, especially those related to special access technology
normally can only be settled by a real test of users using the real
pages on a site, or a good mock up.

Regarding the home page of the web site http://www.masadelante.com/ -
The site with which your email is associated. I would like to say a few
things about this page. Now this site may not be finished, and it is not
entirely clear that this is one of those three Level Triple-A sites you
mentioned you were working on, but there are some points one could look
at in its current state. It has a very nice layout. The all CSS layout
is laudable. It is possible some of the design points, such as the
contrast of the text and background in the upper right hand corner of
the page could be contested on accessibility grounds. I loaded the page
in an XML editor using the XHTML 1.0 Transitional DTD and there were no
validity problems.

The page http://www.masadelante.com/ did not load in my Netscape 4.79
browser, and endlessly kept trying to load - I could not load the page
until I turned off scripting. What is technically accessible according
to the rules may not be accessible in actual use. In Netscape 4.79, this
same page formatted strangely, because not all the CSS was disabled -
the @import rule excluded much of the CSS from this browser, but the
embedded styles and inline styles were implemented. Technically the page
meets basic accessibility guidelines, but if a user were to have an
accessibility problem with this site, it would be a Netscape 4 user.

Other problems with the page:

1. Identify the language of the text. --- LANGUAGE NOT SPECIFIED
(lang attribute for the html element).
2. Separate adjacent links with more than white space. --- SOME LINKS
SEPARATED BY WHITE SPACE ONLY (printing character separator
required between links - the non breaking space is not a printing
character, although it is a character.)
3. If this document is part of a collection, provide metadata that
identifies this document's location in the collection. --- NO
NAVIGATION METADATA (navigation metadata can cause some page
usability problems with older browsers that support the LINK
element). A single page site or a very small site does not
necessarily need navigation metadata. A very large site, due to
the complexity of navigation may make it very difficult to work
out a scheme that works well, as this feature is designed for
document collections such as an academic work with many section,
and many kinds of sites do not have an document structure that
follows this model.
4. Consider specifying a logical tab order among form controls, links
and objects. --- This point is one of those that is more
subjective. If the order in the code is logical, it may not be
necessary to add anything to comply with this guideline.
5. Use the ABBR and ACRONYM elements to denote and expand any
abbreviations and acronyms that are present.
--- The 'A.G.' in 'A.G. Promociones' does not have an expansion of
the abbreviations. Especially when we have pages that are viewed
across cultures, geographical locations and languages, this can
generate confusion. For me, in the United States, I usually
associate AG with German limited liability companies like 'Bayer
AG' (Aktiengesellschaft), and maybe this means the same thing here
although it might be the abbreviation of somebody's name. AG
(usually written 'Ag') can also mean 'agriculture' here in the
United States. 'AG' is the atomic symbol for the metal silver
(although usually written 'Ag'). And other things AG can refer to
are Russian World War I submarines class 'AG' which stands for
'Amerikanski Golland' (American Holland), a particular boat design
of that time. The Russians ordered these boats from some
manufacturer outside of Russia. With the profusion of acronyms and
abbreviations these days, it cannot be taken for granted that the
average person is going to know what a particular combination of
letters means.
6. Consider adding keyboard shortcuts to frequently used links. ---
One might want to add access keys to the main navigation links.
7. Is there distinguishing information at the beginning of headings,
paragraphs, lists, etc.? --- The heading levels in this page are
incorrect; the first heading that appears is h3 instead of h1;
after the h1 everything is fine. This is a problem when
constructing a graphical design that is also accessible. The
heading levels are really designed for more acedemic kinds of
documents, the original idea in developing HTML. Maybe using
STRONG instead of h3 at the beginning might solve the problem.
Headings probably should not be too long, that is, a heading
should not usually resemble a sentence. A heading tags a terse
summary about what information follows.
8. Important Images: note that the company logo is in CSS as a
background image, I think) and contains some information that is
not in text in the page. It might be best to put this image in the
page xhtml so that it will show in older browsers, or if CSS is
turned off.
9. If there is a search feature, are there different types of
searches for different skill levels and preferences? --- A very
small site of a few pages may not need a search feature. The
usability specialist Jakob Nielsen noted during testing of sites
that most users do not use advanced search features.
10. Are there navigation bars for easy access to the navigation
structure? --- YES
11. Do you allow users to customize their experience of the web page?
NO ALTERNATE STYLE SHEETS. Alternately, a server-side mechanism
could provide alternative format. Providing at least one
alternative style sheet is a good idea. Giving the LINK element
title attribute the value "Default" to the main style sheet for
the page will activate newer browsers' ability to select a
non-style sheet rendering from the browser interface without the
user having to go into browser preferences to try to turn it off.
12. Is there a consistent style of presentation between pages? --- YES

This site included a FLASH animation, and gave the user control on
whether to start it - excellent! But the content of the animation did
not have an text-based alternative content for those that do not have
Flash or the required version of Flash. Also there is the guideline
"Synchronize equivalent alternatives with multimedia presentations." to
contend with. Is this Flash animation built using the accessibility
features of Flash 6.0? (I did not check this.)

There are so many things to examine, and so many problems related to the
lack of standardization and things we overlook. An accessible web page
may contain considerably more information than a visual only design, and
combining both visual sophistication, which you have done very well
indeed, and accessibility, especially real world accessibility, is a
dance in which we trip over our own feet from time to time. Practice
makes us better dancers. Aiming for Triple-A compliance is a very good
goal. I have not found it that easy to do. An individual working on a
small site may have a better chance of success here than a group working
on a large site. The difficulties arise because in making an accessible
page, we are trying to combine multiple interfaces into a single entity
- a text interface (both large - a text browser, and small - a
text-based cell phone display), an aural interface, a Braille interface,
a number of possible multimedia graphical interfaces and semi-graphical
interfaces for normal and low vision users. With the current technology
mix, a single page without some kind of server-side processing, and
giving users some users a selectable choice of presentation, probably
will not always work out for everyone. The safe road is to follow web
standards as much as is practical, but real world needs sometimes force
a compromise.

Using Level Double-A rather than Level Triple-A also provides a safety
net. If you think you have Level Triple-A compliance, but in reality do
not, then it is still much more likely you have Level Double-A
compliance. From a cost and experience perspective, Level Double-A is
also a more practical target for most organizations who really want to
provide users with good accessibility rather than the minimum
represented by Level A. If we want Level Triple-A, in real practice,
maybe we need a mythical Level Quadruple-A to aim at.

Terence de Giere
= EMAIL ADDRESS REMOVED =

------------------------------

Mike wrote:

Hello list, This is my first post here, so please excuse me if this has
been covered in the past - I checked the archives, but couldn't quite
find what I was looking for...

I am currently designing three new sites, with the goal of 'AAA' for all
of them. Browsing around the web checking out the 'accessibility' topic,
I have found many sites that are 'AA' and not 'AAA'. I am curious as to
why they don't move forward to 'AAA'... I wonder if this is a some sort
of humility 'towards' the triple a status? Am I being a bit naive in
expecting to create a 'AAA' level site? The sites right now pass Bobby
AAA and Cynthia and a recently developed Spanish 'validator'. WRT {With
respect to} the hand checks, I feel that I am passing the requirements;
however, what if I am misinterpreting this?

TIA - Mike

------------------------------




----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/

From: masadelante
Date: Wed, May 28 2003 9:27AM
Subject: RE: priority ratings
← Previous message | No next message

Terence,

I cannot begin to thank you enough for that absolutely stunning reply to
my query. I am speechless. But I can still type!

First off, I'd like to clear up that the homepage that you evaluated was
not designed with web accessibility standards in mind. The rebuild,
which I am working on (right now actually) is being built with
accessibility standards in mind.

The (currently more important) sites in question are two sites that I am
designing for a department of the local government. I would be more than
willing to pass on a link to you or anyone who would like to have a
glance at them. I have taken care to deal with all of the errors and
warnings that the various validators have mentioned, although at this
moment I still would like to go over a last development pass, focusing
on image descriptions versus alt text, and whether or not I should
include a longdescription. I also need to recalibrate my tabindex
(thanks WinIE) and make some links visible so that the accesskeys
assigned to them work. These, along with some of the points that you
mentioned about our homepage, are things that I think you learn after
your first few attempts at designing for accessibility.

"and you might find that if a number of different accessibility experts
were to make a judgement on certain features, you might find some
disagreement among them"

This is what scares me. I will absolutely do my best to make sure that I
obide by the checklists at the W3C and warnings that I get from the
validators. Once I have done this I would be willing to say that "my
site is AAA". But what if someone comes along and says "this guy is out
to lunch?" I guess that's why I am including an e-mail address on the
page encouraging feedback to do with accessibility issues within the
site.

Thanks again for the feedback and the look at our homepage. In our
defense, that site has been slowly let loose (inline styles etc.) as we
have this new site almost ready to go.

Best regards,
Mike


----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/