WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessibility Observations

for

From: Holly Marie
Date: Feb 27, 2002 5:37AM

From: "Terence de Giere"


> The issue of linearization in a Web page is a tricky one.

Definitely. We cannot forget that more people NEED graphics and Visual
Design function to help assimmilate and digest information. We have
normal and challenged people that need visual design, graphic elements,
diagrams and graphs, charts, etc for help understanding information and
directions. We also have normal to challenged people that not only need
graphics, and visual design aids, but audio, multimedia, or
interactivity.

Linearization of text information is not the only area to hurdle when
designing for accessibility. It is only one. And making sure information
is displayed in a clear order,also helps for non challenged individuals
on portable devices and newer technology.

>
> NESTED TABLES.
> 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.

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.

> Many sites use nested tables to precisely position page items as well.

Absolute positioning can take care of this area well enough also.


> Because tables still need to be used to create graphical layout,
> attempting to simplify and reduce the number of tables can help.

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.

> 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.

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.

> FRAMES.
> Frames also break the linearity of presentation since it forces
> non-visual users to go to separate pages to get information. While
these
> pages appear as a single interface in a graphical browser to the
sighted
> user, this is not so for everyone using text, audio or Braille access.
> For a few, of course, frames do not work at all.

Frames are not impossible to code to work, however they take great care
and also need a non frames version of the same content. A good point
about frames is telling a client or person wanting these, that they will
increase the cost of the job dramatically because the amount of work to
code them accurately will increase. This often dissuades the need for
frames for those that just want them and do not have an idea on what is
involved.

> 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.

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.


> EXPERIMENTAL LINEAR PAGES WITH GRAPHICAL LAYOUT.
> I have created experimental pages that are one column, linear, meet
the
> W3C Level Triple-A accessibility compliance requirement, and display
> with a fixed top and left menu for navigation, and have scrolling
> content as with frames. All these effects can be created with CSS2. No
> frames, no tables.

> *The pages have relative sizing so the user can change the font sizes
> for the content and menus.

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?)


>If the graphical screen is small the menus
> reflow to the next line for the top menu, and a scroll bar appears in
> the left menu. The pages use graphics only in the content area,
although
> of course they could be placed elsewhere too.

I do believe this is where Nielsen and other text only pundits fail, the
need for graphics is just as important as the need to present clear
content without graphics. Read some of Nielsens useit columns that are
highly textual in nature and embedded with facts and percentages etc.
Those types of information would be clearer for the challenged and
normal users as well if they had also had some simple gif graph or chart
image alongside the rolling content.


> *The top menu is actually at the bottom of the page, and the left menu
> just above it. Jump links to the navigation areas at the top of the
page
> are hidden for graphical screen display, but appear in text and
> audio/Braille renditions of the page.

This is fine except you miss the accessibility point of those skip links
for the people using a breath switch or keyboard access to these
links.... If they cannot see the skip link, they may miss the ability to
skip the links and have to slowly access the rest of the links in the
navigation before they reach the content. So skip links in my opinion
should be quite visible to the ones that need to see they are there in
order to use them.

> This means for assistive
> technology, the content can appear first on the page to provide more
> context than a long string of navigation links. A couple of short
links
> can take such a user to those long-winded navigation menus, and
present
> a much shorter obstacle at the beginning of the page. Also search
> engines will index more of the content first, and may display more of
> the actual content rather than navigation bars in their search results
> summaries.
>
> *The pages have alternate style sheets so a linear display version can
> be selected from the menu of browsers that support this feature. For
> example a high contrast large text style sheet that also doubles the
> size of the images was provided.

How are these separate sheets delivered? If with javascript, will they
work with a user that has scripting turned off, are they php delivered
or delivered with the exclusionary @import work around? (@import will
not be delivered to a NN4X or older browser and some have used this
option to sort delivery of different style sheets)

> The page, while totally plain, displays
> fine with the default rendering of older that do not support CSS.

Plain may not work as well for those that need less than plain to access
and understand information.

> Without the "graphical" CSS the page can render well on a very small
> screen. Alternately a more pleasing CSS that does not reposition
> elements could be used for small screens. Of course audio style sheets
> can also be included, once audio browsers and browser/screenreader
> combinations support CSS2.

It could be used anyway, and then the pages will not have to be redone
in the future when these devices become available on non Linux based
machines. EmacSpeak supports the aural sheets from what I have heard,
and would hope that others will follow soon. Aural sheets are an added
enhancement on the delivery of the text through voice and voice
qualities that more closely resemble speech than automated digitized
voice.


> PROBLEMS.
> There are problems however. Visually, different browsers do not
process
> all the CSS functions used: Internet Explorer did not scroll the
content
> or allow the menus to be fixed; Opera mangled the display of the left
> menu. Netscape did not do well if the font size was increased too
much.
> However turning off the style sheet solves all those problems. Only
> Netscape supported additional style sheets linked to the page, but did
> not allow the user to use their own style sheet. All the browsers
showed
> glitches in format.

There are always some problems, but finding and coding to the guidelines
and working with CSS after removing all the deprecated elements from a
page work well when one gets use to knowing what works and does not work
and tests these pages on as many browsers as possible and also in the
non CSS format. I find delorie.com and its backward compatibility
feature online a good resource and I find lynx another. In the meantime,
I code always with CSS, do not code color or presentational items into
my HTML tags, and follow xhtml transitional and strict. This ensures a
page will be ready to be quickly changed or modified, and quickly
changed or modified to fit newer technologies, and works well without
CSS on a text only or Style - Less delivery, if needed.


> THINGS WILL IMPROVE SOON?
> It appears we are close to the time - older browsers notwithstanding -
> that linear, device-independent pages can be created that can have
some
> decent graphical interest and still be highly accessible, and not
> contain any layout tables or frames. The problem I see is, many
graphic
> designers have a certain dislike of layouts that reflow, change shape,
> and may display with some significant difference on different
browsers.

Some designers have a problem with the differences between browser
rendition, but I do think that tide is changing and it is going down a
better path. Now it seems that more designers, and developers are really
looking at the increased possibilities of CSS use, and also the coding
to guidelines avenues. Accessibility is following. S by SW, this year,
has a whole section of the convention devoted to Accessible multimedia,
which is very neat to see. And as these same accessible techniques also
become important to delivery of information and content over portable
and wap devices, or hands free mobile devices in transportation, the
more it will be embraced and used. The Internet and Web are fairly new
in terms of recent history, and there was this unorganized growth in how
to display and produce content for people out there using it, now is the
time they are working hard on creating a better order and cohesiveness
to how the information and content gets delivered. It won't happen
overnight, but I am very pleased to see many of these changes happening
in the last year or two and have a good faith it will come around and
both sides will grow in the future, in a better way.

> CSS is really a simple programming language and its format effects are
> not as easily understood by many visual designers as is making a
> beautiful drawing of an interface in a program like PhotoShop. I have
> watched truly gifted visual artists struggle with CSS in HTML editing
> applications like Dreamweaver. It is difficult to visualize the
effects
> of CSS without playing with it a lot.

I love to do both, and I find CSS one of the neatest things around to
deliver information and content, my eyes and mind are also onto SVG and
how that will greatly improve the delivery of information and content in
the near future and already doing so on the net at a few web sites. SVG
are graphics based on xml language and the graphical information is
actually in text format. Resizeable or rescalable without degradation of
the quality of the image and also very accessible. In time it will be
working even better.


> INTERACTION
> One of the major remaining problems is interactivity. Scripting, or
> embedded that produce motion on the page, and instantaneous
interactive
> changes simply often fail with screen readers. And older technology
and
> browsers do not support these interactive features than do not support
> scripting or plug-ins. Such interactivity can be very non-linear.
There
> does not seem to be a meaningful way to reproduce these effects with
> more static, accessible pages other than to provide a wizard-like
> sequence of form submissions or a transcript.

Interactive Multimedia is a necessity in delivery of information to
normal to challenged populations. Interactivity is a Computer Human
Interface design function. Design = functionality and usability - as
well as delivery of visual information. Providing alternatives is
necessary.

Flash can be very accessible to those with reading problems or even
motor problems where text only content would be inaccessible. You cannot
forget the Whole audience out there when making these statements. Take a
trip to Edmark.com who makes software packages for learning and learning
disabled as well as for multiple handicapped individuals, that may even
use switches, touch screen windows and specialized keyboards. They have
some online interactive demos of some of their programs that are very
neat. Some also quickly change the delivery of the content aurally into
several choices of language.

Cardean University and Unext.com [ http://www.unext.com demos here
http://www.cardean.edu/cgi-bin/cardean1/view/coursedemo_overview.jsp ] a
distance learning project online, uses multimedia, and interactive
multimedia to teach its students..... Two people on the board of that
school and founders also involved in the delivery of content including
multimedia are Jakob Nielsen and Donald Norman of the Nielsen Norman
group and www.useit.com[ http://www.nngroup.com/ ]. Usability experts
themselves. They realize that the use of multimedia for delivery of
content, information, and learning material is VERY important, too. It
increases attention and content retention. As well as comprehension.


> ACCESSIBILITY IN THE DEVELOPMENT PROCESS.
>
> DEPENDENCE ON HTML.
> Because accessibility is so HTML dependent, Web developers are in the
> best position to understand the specific coding issues involved. There
> seems to be a strong tendency to hand off accessibility issues to
those
> who code the final design for a site, simply because the developers
are
> the ones expected to deal with the issue as they create the actual
HTM.

I would quickly emphasize the need to shrug off the reliance on HTML and
switch over to the XHTML model, a much cleaner and streamlined use of
web page code that will deliver better to more devices in the long run.
And prepare the pages for multi types of delivery in the near future....
braille machines, portables, hands free devices, wireless, etc...

> EARLY EMPHASIS ON ACCESSIBILITY.
> But my feeling is as the Web progresses towards greater device
> independence, accessibility really must be confronted early in the
> development process, even before any basic page layout designs are
> created. That is, accessibility for a site should be developed about
> concurrently with data gathering and early usability testing. The
> tendency to push accessibility to a later stage, such as during
detailed
> page design, or even after that, should be resisted. Just as testing
for
> usability early in the development process can save a project from
major
> and costly design errors, the same can be said for accessibility.
After
> all, any inaccessible page is unusable.

This is true, usability should always be a concern, even for the normal
average users. If one has an ecommerce site that is slow to access,
unclear in content, hard to find what you need... normal and
innaccessible users will both have a bad experience and the site and
company will fail. So usability is important on all levels and often
forgotten or overlooked by many.



> TESTING TEMPLATES
> It may be necessary to create linear, testable templates in HTML or
> XHTML early in the design process so that so it can be rendered in
> assistive technology, both for usability analysis and testing with
> assistive technology users. These could be simple HTML pages, the
> equivalent of wireframe layouts created by usability specialists. This
> method is partially backwards from the way sites are usually designed
> now, which takes a visual layout, often usability tested early on with
> low fidelity paper and partially functional screen tests (such as
using
> a block graphic image mapped to simulate links and other functions)
and
> leave the structure for the HTML to be created at the end of the
process
> of design.
>
> Thus accessible/usable design may require doing some more coding up
> front in the process. Then, once a satisfactory solution is found, the
> page can be worked into a more detailed design and eventually
formatted
> into a graphical design using CSS. The trick, if the same page is used
> for accessibility and the graphical layout, is to coordinate what is
> possible and not possible with CSS to implement the graphical design,
> and what kind of compromises are possible.
>
> Creating an accessible, correctly structured HTML and adding format
> later or working out details of both aspects of design - HTML
structure
> for accessibility, and graphical presentation concurrently is not
> something most usability specialists, graphic artists and developers
> have had much practice with. Right now usable accessibility tends to
be
> compromised in favor of graphical design and usability for normal
users,
> but I do not think this compromise will be ultimately necessary.

I like to do this the other way around. I like to formulate a nice open
design that will be clear to all users, then apply the code and layout
with code to make it work across deliveries. I find that easier than
just starting with a page template and changing about code. Working up a
demo in a graphical format then applying code is quite fun to me.


> WE HAVE SOME BAD HABITS; GOOD LOOKS AND GOOD FUNCTIONALITY MAY BE
DIFFERENT

> The idea of a fixed immutable design does not work with the second
> generation Web. Device independence and good accessibility require
that
> the basic information structure and navigation of a page and a site
hold
> up under a lot more diverse conditions than that of simply looking and
> functioning the same on Internet Explorer and Netscape on a desktop
> computer monitor with a fast connection for a normal, sighted,
> mouse-happy user.


XHTML + CSS --- Testing on all fronts --- and then ---> items of XML

this is what should be worked on now.... and this takes care of the bad
older habits, while preparing pages for portability to many and more
devices and usability now and in the future.

holly



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