E-mail List Archives

RE: Accessibility Observations - response to Holly

for

From: Ian Burrett
Date: Feb 28, 2002 6:48AM


hi there newbie here,

I have to agree with Holly on the css and tables issue. detecting the
browsers is very simple and this can then take the user down an entirely
linear path, with all the same content only parsed into a linear layout.

meanwhile those users with browsers that support css fully (or as near as
possible) can then take a different layout.

I have done this recently and with a bit of site planning the structure can
more than cope - maintaining doesn't mean hassles either.

Ian

-----Original Message-----
From: Holly Marie [mailto: <EMAIL REMOVED> ]
Sent: 28 February 2002 13:44
To: <EMAIL REMOVED>
Subject: Re: Accessibility Observations - response to Holly



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/

***********************************************************************
This e-mail, and any attachment, is privileged information and its
contents are confidential to the intended recipient at the e-mail
address to which it has been addressed. It may not be disclosed to or
used by anyone other than this addressee. If received in error, please
contact Learning & Teaching Scotland on +(44) 141 337 5000 or e-mail
<EMAIL REMOVED> , quoting the name of the sender and the
addressee, and then delete it from your system.
Please be aware that, although all reasonable steps have been taken,
neither Learning & Teaching Scotland nor the sender is able to accept
any responsibility for viruses.
No contracts may be concluded on behalf of Learning & Teaching
Scotland by means of e-mail communications.
The contents of this message may contain personal views which are not
the views of Learning & Teaching Scotland, unless specifically stated.
**********************************************************************


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