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: Thu, Feb 28 2002 12:45AM
Subject: Re: Accessibility Observations - response to Holly
No previous message | Next message →

THE ACCESSIBILITY OBSERVATIONS THREAD SEEMS TO HAVE INSPIRED A LOT OF
WONDERFUL COMMENTS. Holly Marie made some good observations on some of
the things I said, so I suppose I should defend myself, or amplify my
statements by way of her more pointed comments, which, based on what I
had written, are true.

TERENCE'S ORIGINAL STATEMENT
The only way, for now, to linearize complex pages with intense graphical
layouts is with pages which have many discreet complex areas created by
making nested tables. Any browser or browser/screenreader combination
that can read tables will linearize the sequence of the page properly.
But those nested tables will present barriers for users of some kinds of
technology, ones that cannot turn off reading of table structure. Just
having a new table itself announced every few words could be annoying;
some technology will read the start of every row and cell as well.
Many sites use nested tables to precisely position page items as well.
This can create a large number of nested tables whose function is not to
establish the linear flow of the information in the page; they may even
scramble the order of presentation with the most recent assistive
technology.

HOLLY'S COMMENT:
Nesting tables is not the only way to do this, not now.

Not true and should NOT be used. Nested tables can lead to the one of
the more innaccessible ways to deliver a page if not extremely careful,
AND nesting tables is NOT allowed in XHTML Strict. It not only confuses
the screen readers and screen reading browsers, it confuses many devises
and mechanisms that parse page code and deliver the result.

The same effect can be delivered with Style sheets, and divisions.

TERENCE'S RESPONSE

Yes, this is right. However I have had to produce templates that really
required tables because of a browser support issue. The only way to
linearize the design for the assistive technology in question was to use
nested tables, not CSS. While this knocks off certain assistive
technology, it allowed a very dense design that linearized properly with
recent versions of JAWS, Lynx, and the now defunct pwWebSpeak32 audio
browser. This was for an intranet for which presumably, or hopefully,
the company could control the hardware and software used. The design was
created by a team of ergonomists, and while the goal was to be
accessible, accessibility was really given a brush over and the final
result was technically correct according to the rules, but difficult to
implement as usable accessibility at W3C Level A. Unfortunately
accessibility is not always the key element in a design, but a
compromised element. In this case highly usable visual design with
extreme compactness for a lot of material and navigation were the
primary goals.

I agree that nested tables for format and positioning are really bad,
but with the most recent screen readers, it does work, because the
screen readers are not just reading what the browser prints to the
screen but have hooks into the browser itself, allowing it to get
information on the HTML element structure. I prefer the DIV method
myself, but do not like absolute positioning with pixels or fixed
measurements in most cases, if the desire is to create a page than can
fit multiple screen sizes including rather small ones, such as on a
graphical PDA browser that supports CSS.

Nested tables are a technique for linearizing the text flow with certain
assistive technology. The Section 508 rules do not prohibit this. And
single column pages are only required by Level Triple-A conformance in
the W3C WAI guidelines: 10.3 Until user agents (including assistive
technologies) render side-by-side text correctly, provide a linear text
alternative (on the current page or some other) for all tables that lay
out text in parallel, word-wrapped columns.[Priority 3]. This is the
last level you can expect a corporation to spend money accommodating.

I was thinking of the issue of older browser support, and specific
problems of CSS support using percentage values with absolute
positioning rather than fixed measurement such as pixels or centimeters,
etc. The best CSS browsers still do not handle this more relative use of
"absolute" positioning very well, with especially annoying variations in
the positioning of boxes and problems with overlapping incorrectly and
text overlapping incorrectly. Rendering this fluid, unfixed layout must
be difficult for the developers of browsers to figure out and code. They
just have not got it yet. Forgive my incompleteness, but there is always
more to learn and remembering everything is for the gifted few.

TERENCE'S ORIGINAL STATMENT:
Because tables still need to be used to create graphical layout,
attempting to simplify and reduce the number of tables can help.

HOLLY'S COMMENT:
Again this is not true, there are many ways to present graphical layout
without the use of nesting tables, without the use of tables, and with
the current elements of code and guidelines.

TERENCE'S RESPONSE:
Yes I agree. But if you want to accommodate visually some of the older
browsers, tables may be the only way to implement a graphic design. I
had to create templates for a group that included teachers, who tend to
have older browsers and the company specifically required that Netscape
3.0 be supported, and there would be no coding to customize for specific
browsers. To make the design work for the browser mix, tables had to be
used, and accessibility was not part of the specification. Had
accessibility been implemented, Section 508 or Level A, it would not
have been ideal but would have been workable with this use of tables. So
if tables must be used, alas, simplify if possible. By the way, the
graphic designer that created the visuals for the site referred to here,
when left to his/her own devices produces completely inaccessible sites,
and uses graphics without ALT text for everything including most text on
the page.

Note that the W3C home page still uses a simple table for layout in
three columns; not nested, which is good. Interestingly, a link to an
alternate page that was only one column now seems to have been removed.
Again forgive my incompleteness, but practical realities, unfortunately,
are often the bane of accessibility.

TERENCE'S ORIGINAL STATEMENT:
OLDER SCREENREADERS.
Some combinations of browser and screenreader cannot read information in
columns created by tables. Those readers just read horizontally across
the screen, cutting across the table boundaries and making the page
incomprehensible. The only solution for these users is a single column page.

HOLLY'S COMMENT:

Now here is a nice sticky area. Do we as designers and developers
continue to design backwards for old technologies and browsers or do we
fully embrace the guidelines and current rules or suggested coding and
leave it up to the end user to bring themselves up to the current
technology.

Do we continue to design for NN4 and older versions, keeping that type
of incomplete and backwards code alive, or do we all try to move forward
and at the same time the people developing and or using older technology
will need to upgrade?

Isnt it our job to follow the recommendations and code to guideline and
then the end user's job to make good use of the technology as it should
be? Coding for accessibility is not easy, but not impossible, and can be
easier than some ways are portrayed. A good dose of common sense is
quite often the missing element. The other is an awareness that
accessibility is NOT only about the blind, but also about dyslexia,
reading difficulties and non readers, motor challenges, normative aging
and age ranges of users, hearing and hearing impaired, and many more
considerations. Including the usability and challenges of a *normal
average* user.

TERENCE'S RESPONSE:
O that those older browsers would expire, primarily the ones that
support CSS incompletely. Each Web site has some agenda behind it. Where
to break off support is always a big issue. For accessibility supporting
older technology is good, because these AT (asssistive technology) users
may be using older computers and browsers as they tend to have less
income for upgrades etc. Right now I have a blind friend who is stuck
with Windows 3.1 and older assistive technology.

However for supporting accessibility, one does not necessarily have to
support the visual aspect of CSS format for those browsers. Turning off
CSS support at the server is best (browser detection and ASP or JSP or
similar page construction that can substitute different style sheets or
leave them off), but less technically constructed sites may have to do
with single pages and no ability to control the issue. Using JavaScript
is less perfect, because the user could turn it off, and forces one to
add a NOSCRIPT equivalent or explanation. If more than one person is
involved in the decision, you may have to compromise. My personal
preference is to aim for the Web standards. The Web really needs a
standard API for all this to work. Anybody want to vote on which CSS
browsers to axe? I vote for Internet Explorer 3.x and Netscape 4.x, to
start.

TERENCE'S ORIGINAL STEMENT:
CASCADING STYLE SHEETS LEVEL TWO.
The solution is Cascading Style Sheets Level Two (CSS2). Unfortunately
the positioning aspects of CSS2 are still limited and quirky in the most
recent incarnations of the graphical browsers. The recent browsers
however, show the promised land is getting closer.

HOLLY'S COMMENT:
I have to disagree here and worked a fully compliant absolutely
positioned page that not only lays out well in all browsers... NN4x,
IE5.5, Opera, Mozilla, and NN6, but it also degrades gracefully and in
clear order on a text only render in Lynx or browsers with sheets and
styles off. So that is a bit of misinformation. The pages coded to XHTML
strict without error or warning and the pages also coded to CSS2
Validation with no errors and no warnings, and on further check read
well on text only. So it can be done well and does work well enough both
visually and contextually.

TERENCE'S RESPONSE:
Again, without stating fully what I was thinking, I was referring to
absolute positioning with percentage values that do not yet work well
across the browsers. Holly's example shows that absolute positioning
with fixed units of measurement is quite workable.

However Holly's page linearized in Opera 3.62, the first CSS version of
that browser which only supported CSS1 and not CSS2 positioning, and was
difficult to read as text overlaid the grid background graphic.
Fortunately that version of Opera allows quick switching to a user mode
that removes the style sheet format. Using relative values is a Prioity
2 item with the current W3C rules and so for Section 508 and W3C Level A
accessibility compliance, we can ignore and use fixed font sizes and
fixed page widths etc., which some browsers do not allow the user to
override, at least without going deep into the browser preferences.

The usability expert Jakob Nielsen found that users using screen
magnification performed less than half as well on tasks as normal
sighted users. With a fixed width page enlarged, horizontal scrolling
becomes a big usability issue. The goal is to try to reduce the
scrolling by having the page reflow and become narrower for these users.
Of course with really big enlargement, this cannot be fully prevented.
Some users, such as those with advanced macular degeneration may have to
read almost letter-by-letter.

The example Holly created is quite nice at
http://www.qexo.com/access.html. The font size is normal - not too small
like most Web sites these days. The contrast may be too low for some
users. The orange background and blue links is slightly chromosterioptic
and should be avoided. Chromosteriopsis results when colors are side by
side as text on a background and the wavelengths focus at different
depths in the retina causing a 3D effect of the text lying outside of
the plane of the background. Red and blue is the worst combination. The
effect on Holly's page is much more subdued as the wavelengths are
closer together.

EXPERIMENTAL LINEAR PAGES WITH [CSS] GRAPHICAL LAYOUT.

HOLLY'S COMMENT
If these areas for the menu and navigation are fixed, what happens to
the text when a users resizes it say 300% or more, does that content get
cropped off or hidden? (do you have an overflow statement for the
content in the css?)

TERENCE'S RESPONSE:
In these pages the menus were not completely fixed. They could reflow to
some extent. There is a problem with increasing text size right now. The
Mozilla browsers do not increase the line height if line-height
specified in the CSS and so the text jumbles together. Internet Explorer
handles this situation much better, by proportioning the line height to
the text. Opera also handled text size increase fairly well, but
normally in Opera one can just magnify the whole page more easily. There
is a way to go here as far as how the browsers handle this issue. There
seems to be some hope, but it is not right yet. Internet Explorer could
not position the menus correctly on the page without absolute
positioning (The ideal sample used fixed positioning so the menus were
always visible, or scrollable).

As for the skip links, these were *to* the navigation area, not to skip
over it. The navigation links on the page were not where they appeared.
In Opera the first element on the page accessed when in graphical mode
was the first H1 Heading in the content area. You have a point about not
being able to see the links though, if the user needed to get *to* the
navigation and had such restricted mobility. Keep me thinking! I am all
for just putting these links in text and be visible, but graphic
designers often hate this, so part of the experiment was to hide them.
This is where usability testing can be helpful. More experience is also
more helpful in solving these kinds of problems. It does not appear we
will be able to solve all the problems equally well to the satisfaction
of everyone.

ACCESSIBILITY IN THE DEVELOPMENT PROCESS.
DEPENDENCE ON HTML.
Actually the current dependence is on the HTML element names. These were
of course carried over into XHTML. Pure XML without predefined element
names such as H1, H2, H3 etc. does not have any standard way to
establish document structure for accessibility unless the element names
become standardized and supported by the technology. Otherwise it
becomes necessary to have a style sheet (CSS or XSL) provide the proper
rendering, which won't work in a non-CSS or non-XSL browser.

As for Holly's other comments, she will keep me on my toes. Design is an
iterative process. Exactly what must be done first, the text-only
sequence, or some graphical layout? In the end it may come out the same.
I have focused on issues related primarily to non-sighted, or text
access, which requires a text-based approach to the content, but Holly
wisely pointed out that multimedia and imagery is essential for certain
learning disabilities.

(Holly, I am a photographer, with a passion for landscapes, and have a
very non-verbal approach to imagery, at least in photographic media; I
am slightly rusty at it since I have been in front of a computer for the
last half-decade.) A picture is worth a thousand words both in content
and code size. One of the most difficult things to do well is describe
pictures well and completely in text. Another difficult task is
designing usable multimedia and also making that material accessible to
those that cannot experience imagery or sound.

For those with textual impediments, does this mean that we have to
create imagery-only equivalents to predominantly text based pages? My
guess this would be done for special training programs, but ordinarily
would be overlooked as a possibility since accessibility guidelines
focus more on text equivalents for multimedia rather than the opposite.

I found everyone's comments on this thread of general accessibility
observations really illuminating. Thank you everyone for such a spirited
collection of useful comments. We all learn, and when we forget
something, it reminds us.

Terence de Giere
= EMAIL ADDRESS REMOVED =



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

From: Holly Marie
Date: Thu, Feb 28 2002 6:44AM
Subject: Re: Accessibility Observations - response to Holly
← Previous message | No next message

From: "Terence de Giere"



>
> TERENCE'S RESPONSE
>
> Yes, this is right. However I have had to produce templates that
really
> required tables because of a browser support issue. The only way to
> linearize the design for the assistive technology in question was to
use
> nested tables, not CSS.

I am curious about the need for these nested tables. If the information
becomes linearized, could this information be delivered with a different
layout in a linear way?

Most often when I see nested tables on a site, it is because someone
wants to put to use some borders and decorative features around tables
and cell edges. I know that CSS for tables is incomplete in support,
especially with NN4x and older forms of IE, however, these same effects
can be arrived at with a single table and creative use of division box
models with borders of varying sizes for tables and cells.

Someone I know did this recently and had a page filled with various
tables, both nested and sequential. The problem not only with parsing
and possible out of order information on some readers and speakers that
may not be able to sort out these table issues, is the real fact that
more tables on a page = more code and tags = more time for the next
revision, update and fix AND also means more time for devices to parse
this code and display it. So for quicker, cleaner, leaner, and easier to
maintain and easier to digest information and pages... One table and use
of CSS as well as no tables and use of CSS may in fact work better all
the way around. For the user, for the company, and for the
designer/developer or future designer/developer.

My thoughts... code a page in CSS, if an older browser does not support
CSS on - let it deliver linearly.


> While this knocks off certain assistive
> technology, it allowed a very dense design that linearized properly
with
> recent versions of JAWS, Lynx, and the now defunct pwWebSpeak32 audio
> browser. This was for an intranet for which presumably, or hopefully,
> the company could control the hardware and software used. The design
was
> created by a team of ergonomists, and while the goal was to be
> accessible, accessibility was really given a brush over and the final
> result was technically correct according to the rules, but difficult
to
> implement as usable accessibility at W3C Level A. Unfortunately
> accessibility is not always the key element in a design, but a
> compromised element. In this case highly usable visual design with
> extreme compactness for a lot of material and navigation were the
> primary goals.

When you say a lot of material, Now I am wondering about font sizing,
etc?
Tables with CSS can be used and the flow of resized text will rearrange
in the table cells on a resize.
These, again can be very simple designed unnested tables and other
elements can be added with CSS. I would venture to say over 90% or more
of the browsers out there support the basics of CSS which could be used
in this way.
I would have to take a look at www.eleganthack.com and www.echoecho.com
to get the latest or most current information on this.


> I agree that nested tables for format and positioning are really bad,
> but with the most recent screen readers, it does work, because the
> screen readers are not just reading what the browser prints to the
> screen but have hooks into the browser itself, allowing it to get
> information on the HTML element structure.

Yet this is a bit contradictory, you speak of older technology and
devices or assisstive technolgy here, yet you speak of nesting tables.
Some of these older devices and technology cannot even parse or deliver
a standar simple table with simplified columns(no row spans etc). How
will they be able to parse nested items?

> I prefer the DIV method
> myself, but do not like absolute positioning with pixels or fixed
> measurements in most cases, if the desire is to create a page than can
> fit multiple screen sizes including rather small ones, such as on a
> graphical PDA browser that supports CSS.

There are some table less column models out there. I have not checked
them all and some do provide for text resizing and flowing the text down
a column, even at one word on a line, if necessary. A good starting
point may be to start checking out the CSS models and references at
Glish.com. He has collected some innovative models that replace the need
for tables. Again, not all of these designs may be to liking but many
might work for what is needed and how it is needed. If people with
macular degeneration need to boos text to 500% or more, one word such as
technology will surely go wider than a 19 inch monitor at any rate and
that sideways scan and word by word reading is going to take time
whether one is scrolling sideways or down a page to tell the truth. So I
really do not think scroll is the biggest issue here, they are going to
be scrolling with difficulty in either direction.[I am very aware of
various vision situations, as I worked in this area for a few years
before having children]

And when those people zoom the pages as large as they are going to need,
how is it those columns are all on the view anyway. those would need to
be scrolled and they won't be benefitting by the nature of such layout?



> Nested tables are a technique for linearizing the text flow with
certain
> assistive technology.

Without seeing the nested structure, I cannot really comment much more
about it, but surely there must be some design options to split this
information up better, or chunk it into sections and deliver it more
linearized?

Again, if it is a matter of borders, colors, cell color differences ,
etc... much of the same can be achieved with tables and divsions, but
without the need for nesting?

>The Section 508 rules do not prohibit this.

No, but the XHTML strict rules prohibit this, and XHTML is padding the
way for use of XML which will be the key item that delivers the content
to a wider array of devices, from braille output to wireless....

>And
> single column pages are only required by Level Triple-A conformance in
> the W3C WAI guidelines: 10.3 Until user agents (including assistive
> technologies) render side-by-side text correctly, provide a linear
text
> alternative (on the current page or some other) for all tables that
lay
> out text in parallel, word-wrapped columns.[Priority 3]. This is the
> last level you can expect a corporation to spend money accommodating.

Well, I agree that corporations are not going to be happy about
complying with changes and different ways of doing things. We entered
this Internet on an explosion of development, ideas, and ways to do
things. We found out there is a multitude of items out there that was
not so good to use and for good reason. We are in the age now of sorting
through all the rubble of overquick development and trying to get a
handle on some conformance and some set of common goals. In order to
make it all work, tools, software, designers, and developers will all
have to bite this bullet and try and work with the same sheet of rules,
guidelines, and instructions - to get it to work smoothly and transition
quicker to a place where it can all be finely used. My honest opinion -
continuing to support old hacks and backwards ways - will forstall or
slow this development into the right direction.

> I was thinking of the issue of older browser support, and specific
> problems of CSS support using percentage values with absolute
> positioning rather than fixed measurement such as pixels or
centimeters,
> etc.

This can always be an issue, unfortunately. I myself am not looking for
picture perfect exactness among browsers, and realize that there are not
only differences among browsers and also among OS, but there are
differences between user settings - so there is no way we can really
deliver anything that is exact for everyone across every medium. Save
for Flash and PDF which have some issues with access of their own. Flash
though, can be very accessible to those with lower vision because it
zooms and the picture does not distort as much as an HTML: page might.
PDF on the other hand, as a normal user, I find it very clunky and hard
to use, pages do not forward smoothly or scroll smoothly, I just find
the whole interface a nightmare and I have all the capabilities of use.

>The best CSS browsers still do not handle this more relative use of
> "absolute" positioning very well, with especially annoying variations
in
> the positioning of boxes and problems with overlapping incorrectly and
> text overlapping incorrectly. Rendering this fluid, unfixed layout
must
> be difficult for the developers of browsers to figure out and code.
They
> just have not got it yet. Forgive my incompleteness, but there is
always
> more to learn and remembering everything is for the gifted few.

Lots of experimentation is needed along with checking and making sure
the pages work in as many ways and deliveries as possible, for those
that do not support CSS the pages should linearize and be deliverable as
a text only type document.


> TERENCE'S ORIGINAL STATMENT:
> Because tables still need to be used to create graphical layout,
> attempting to simplify and reduce the number of tables can help.
>
> HOLLY'S COMMENT:
> Again this is not true, there are many ways to present graphical
layout
> without the use of nesting tables, without the use of tables, and with
> the current elements of code and guidelines.
>
> TERENCE'S RESPONSE:
> Yes I agree. But if you want to accommodate visually some of the older
> browsers, tables may be the only way to implement a graphic design. I
> had to create templates for a group that included teachers, who tend
to
> have older browsers and the company specifically required that
Netscape
> 3.0 be supported, and there would be no coding to customize for
specific
> browsers. To make the design work for the browser mix, tables had to
be
> used, and accessibility was not part of the specification.


Regarding Teachers and speaking of education in the mix, I find it
rather surprising(and also not) that accessibility guidelines are not
important here. It was my understanding, though grant restriction and
funding actions would not be taken, that educational, governmental and
other key public entities needed to really embrace accessibility issues
and work at compliance?


> Had
> accessibility been implemented, Section 508 or Level A, it would not
> have been ideal but would have been workable with this use of tables.
So
> if tables must be used, alas, simplify if possible. By the way, the
> graphic designer that created the visuals for the site referred to
here,
> when left to his/her own devices produces completely inaccessible
sites,
> and uses graphics without ALT text for everything including most text
on
> the page.

This is our fun and challenging job here. To make a site that is
accessible and also work with all of the people, as we clean up some
older not quite as accessible code.


> Note that the W3C home page still uses a simple table for layout in
> three columns; not nested, which is good. Interestingly, a link to an
> alternate page that was only one column now seems to have been
removed.
> Again forgive my incompleteness, but practical realities,
unfortunately,
> are often the bane of accessibility.

Nothing wrong with simple table use at all, they can be highly
accessible if care is taken in coding these. Yeah I hear you, even the
college sites I used during school were not only innaccessible to
challenged, they were often lacking coherent usability for the normal
users.


> TERENCE'S ORIGINAL STATEMENT:
> OLDER SCREENREADERS.
> Some combinations of browser and screenreader cannot read information
in
> columns created by tables. Those readers just read horizontally across
> the screen, cutting across the table boundaries and making the page
> incomprehensible. The only solution for these users is a single column
page.

I wonder, and do not know nor have my hands on any older readers or
speakers, but I wonder if DIV as containers for text, tables or not,
would keep a reader in the DIV box before moving onto the next? Do these
older readers and browsers not even embrace Paragraph tags? if they do,
simply wrapping content for each cell in paragraph tags would be another
idea? Seems to me that these older browsers must be reading the face of
the delivered page and not the text in the source code, otherwise that
would be linear in nature, unless key thoughts and content were divided
between cells by the developer designer. In which case it is not really
the fault of the screen reader or speaker but that of the designer or
developer for splitting content up in such a way, and an item that could
be fixed. The most often poor use I have seen of this is splitting up
forms - entry boxes from leading text, etc.... so that a form lines up
nicely to the visual users. This can be really confusing to someone who
cannot see a form.

A comment I had from a professor I worked for who was also 100% blind
and taught ecommerce and marketing on the wwww, said that when I coded
the forms, they made sense to him. I asked him why.... he said because
the input boxes that needed to be filled followed the text before the
box....

example First Name [ input box ] all on the same line, not in
different cells or rows... etc...

He had said quite often he ran into forms, which he said next to tables
was one of the things he did not look forward to(He uses Jaws) - forms
were almost always the most confusing. Many times people might put the
text after the input box, or important information after the drop downs
or check boxes etc.... which would mean that after going forward and
reading the text after the form tag, he would have to back track and
redo the form input or choice. This is not only time consuming and forms
are to begin with, it is also confusing to the non sighted.
[I worked with web design projects and some consulting, etc.]


In my reply to should we continue to support old ways...

> TERENCE'S RESPONSE:
> O that those older browsers would expire, primarily the ones that
> support CSS incompletely.

For an experiment, I popped my pages into CERN Line Mode(before
hyperlinks), NN1, Mosaic, NN2, etc... I popped those pages into
something that tests against HTML2(the no tables and the tables
versions), HTML 3, etc... the page displayed linear and fine where there
was no CSS support. Exactly as intended. It made sense without CSS
supporting it, and that is what would work fine. Now, if you have a
nested tables page I would wonder what happens in a browser that does
not support tables? this can be checked either at the HTML2 first
revision [the first drop down here -
http://www.delorie.com/web/purify.html ], or at
http://www.delorie.com/web/wpbcv.html where you can turn off or not
select table support and see how it displays. I would imagine, readers
and speakers that do not support tables, might get the information at
best in this table less preview and may get it even more jumbled? [again
you can turn off images, css, scripts and other items for testing
different displays here also]

It might be good to check this out and see. Does a page make sense with
tables Off? I have put table coded pages through that test, to check for
myself. Just in case I overlooked something while coding. This way I
could make the adjustments as needed.


>Each Web site has some agenda behind it. Where
> to break off support is always a big issue. For accessibility
supporting
> older technology is good, because these AT (asssistive technology)
users
> may be using older computers and browsers as they tend to have less
> income for upgrades etc. Right now I have a blind friend who is stuck
> with Windows 3.1 and older assistive technology.

Again if the pages display ok in the old line mode browsers, and against
old table less guidelines, then I think the page has some potential for
being accessible. And this can work with current code guidelines. All
the presentational elements are stripped away, and only fed in via css.
All else is left to user or browser default, which ever is used and that
is fine for it to be that way. We should not take away the ability for
others to view the pages the way they need to view these.

> However for supporting accessibility, one does not necessarily have to
> support the visual aspect of CSS format for those browsers. Turning
off
> CSS support at the server is best (browser detection and ASP or JSP or
> similar page construction that can substitute different style sheets
or
> leave them off), but less technically constructed sites may have to do
> with single pages and no ability to control the issue. Using
JavaScript
> is less perfect, because the user could turn it off, and forces one to
> add a NOSCRIPT equivalent or explanation. If more than one person is
> involved in the decision, you may have to compromise. My personal
> preference is to aim for the Web standards. The Web really needs a
> standard API for all this to work. Anybody want to vote on which CSS
> browsers to axe? I vote for Internet Explorer 3.x and Netscape 4.x, to
> start.

The other alternative, of course, is to deliver an alternative model or
have one handy. A text only model, which would be ideal for many cases
of printing too. So this would take care of two issues.

The problem with offering a text only or alternative page is to make
sure the content is as up to date as the non text only version. This can
be achieved by using PHP or other server side programming to deliver
content, and requires a bit more work, but thinking of it another way,
it cuts out a lot of work if someone programs this feature in the right
way.


> TERENCE'S ORIGINAL STEMENT:
> CASCADING STYLE SHEETS LEVEL TWO.
> The solution is Cascading Style Sheets Level Two (CSS2). Unfortunately
> the positioning aspects of CSS2 are still limited and quirky in the
most
> recent incarnations of the graphical browsers. The recent browsers
> however, show the promised land is getting closer.

Sometimes, a use of mixed fixed and relative works, too. Fixing one area
and letting another expand or contract is another option to work with.



> TERENCE'S RESPONSE:
> Again, without stating fully what I was thinking, I was referring to
> absolute positioning with percentage values that do not yet work well
> across the browsers. Holly's example shows that absolute positioning
> with fixed units of measurement is quite workable.

While the Areas were fixed the content was not either hidden or fixed,
so the fonts could be resized by the users.
Fixing the container for those fonts to be resized would keep them in a
certain span width. The only one that increases the whole page with font
increase seems to be the Opera browser. The zoom feature is very good on
Opera but it also resizes the whole page view, so naturally there will
be a sideways scroll on a very zoomed view. I am not sure about other
devices like window eyes, etc.


> However Holly's page linearized in Opera 3.62, the first CSS version
of
> that browser which only supported CSS1 and not CSS2 positioning, and
was
> difficult to read as text overlaid the grid background graphic.
> Fortunately that version of Opera allows quick switching to a user
mode
> that removes the style sheet format.

Chances are that if someone is using Opera, and also not needing nor
desiring CSS to be on, they have a good handle on how that browser works
and it is very easy to toggle off the CSS mode and display the page as
text only. In which case a page will deliver as a text only page and
work well.

>Using relative values is a Prioity
> 2 item with the current W3C rules and so for Section 508 and W3C Level
A
> accessibility compliance, we can ignore and use fixed font sizes and
> fixed page widths etc., which some browsers do not allow the user to
> override, at least without going deep into the browser preferences.

Interestingly enough Relative sizing on tables is discouraged by bobby
and percentages are not supported on table sizing, which I found a bit
backwards. So absolute sizing on tables is preferred by bobby? I will
have to check this but think this is true.

> The usability expert Jakob Nielsen found that users using screen
> magnification performed less than half as well on tasks as normal
> sighted users. With a fixed width page enlarged, horizontal scrolling
> becomes a big usability issue. The goal is to try to reduce the
> scrolling by having the page reflow and become narrower for these
users.
> Of course with really big enlargement, this cannot be fully prevented.
> Some users, such as those with advanced macular degeneration may have
to
> read almost letter-by-letter.

They still have to scroll word by word, vertically then too. But I do
see a point here. Sometimes much of this is unavoided. A large word
zoomed in on, will scroll no matter what. I am not sure a word will
break into letters on the vertical and IF it does, I would think that
might be more troubling and innaccessible.


> The example Holly created is quite nice at
> http://www.qexo.com/access.html. The font size is normal - not too
small
> like most Web sites these days. The contrast may be too low for some
> users. The orange background and blue links is slightly
chromosterioptic
> and should be avoided. Chromosteriopsis results when colors are side
by
> side as text on a background and the wavelengths focus at different
> depths in the retina causing a 3D effect of the text lying outside of
> the plane of the background. Red and blue is the worst combination.
The
> effect on Holly's page is much more subdued as the wavelengths are
> closer together.

These colors were picked via a web site on color blindness from a color
scheme chart, on best colors to use for web page design. So I took some
time in choosing those odd colors for visibility on a color blind site
and then popped it into another online check to see if it worked well
there too.

Speaking of contrast, sometimes White text on black or black text on
white, vibrates or is too much contrast. When I use a white background,
I often use a background that is slightly off white and text that might
be dark gray but not black. I find the readability of such text easier
on the eyes. Some colors to non color blind viewers are very difficult
to read as text for long spans. And those might include yellow and red
which tend to bleed on the screen. And become blurry. Bolding some text
also makes it more difficult to read, opposite of what some may think as
being easier to read. Reading bolded text is very hard on the eyes for
long stretches. There is a lot to consider regarding text and vision for
both sighted and low vision users. A possibility would be to offer a
page via Styles that customizes a view? Again either this would have to
be done via some programming feature or even javascript which a user
might not have enabled on their browsers.


Lastly, I do not make any comments to debunk or disagree with a line of
anyone's thoughts, but I make comments to things I have some experience
with, and maybe have some intuition about. Accessibility issues are
neither black nor white and sometimes sacrifices or compromises have to
be made. Thought has to be directed also beyond the scope of one group
or individual and into a wider audience or range of users, too. Again,
often some fixes for one group, makes something inaccessible to another
group, and somehow we need to look at all these items and make some
sense out of it. There will usually be at least one person or more that
may be affected negatively by a change, and hopefully we can arrive at
some point where it works for more people.

By the way. I am also a photographer, artist, designer,... and work with
multimedia. I would like to find ways to incorporate multimedia use for
those that have difficulty with communication, literacy, and reading. I
am also aware of those with visual difficulties. I have a daughter that
has been using Assisstive technology for 18 of her 22 years. She is non
verbal, does not read, write and uses limited signs. She also has some
very cool adaptive equipment for the computer and a specialized
communication device, that is fully interactive and not only will string
icons and animated icons into sentences to communicate via her choice,
it will also speak typed sentences and paragraphs. The device also has
infrared capabilities that can operate any home device with the same. It
is a tiny portable computer with an LCD screen about the size of an
Encyclopedia. CD-ROMs and multimedia are great for her and others with
Cerebral palsy and also with motor and cognitive issues. So, I come from
that camp, which is why I not only know issues of vision, but also
issues of motor, cognitive, communications, and special devices. She has
a touch window for the monitor too because her eye hand coordination for
using a mouse or keyboard(she has a special one) may not be the best,
either.

And I also worked a long while for an out of state Blind professor and
am now working along with or have met a person who belongs to
Blinux(blind linux users group), who sees but also writes programs,
authors, designs web pages, and works with emarketing and small busines
ideas online.

So, I am really focussed on accessibility for all groups, and need some
extra research regarding hearing.

And do not forget the normal populations that also need graphics and
other implementations to understand, learn, and obtain information in
better ways.

Nice to meet you, Terence, and yes, I do understand the frustrations of
a lot of this, but the challenge is a good one, to try and make things
better and more accessible to more.

holly



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