E-mail List Archives

Search E-mail List Archives for

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

From: Terence de Giere
Date: Tue, Feb 26 2002 10:07PM
Subject: Re: Accessibility Observations
No previous message | Next message →

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

COMPLEX GRAPHICAL PAGES FOR DATA ENTRY AND RETRIEVAL.
There are many processes that can be made very efficient for normal
users with a graphical interface. An example would be a very dense
screen used by employees of a courier service for tracking packages.
Such a screen would have multiple options, scripting functions, data
windows etc. Typical users would be trained in the use of such an
interface, allowing it to be more complex than a typical screen on the
Internet that would be used by first time user.

RETROFITTING LINEARITY.
Making such a dense screen accessible and usable for a screen reader can
be quite difficult, especially trying to linearize the tasks in a
meaningful way. Once the visual relationships are gone, a lot of the
efficiency and power of the interface is lost. A new set of
relationships needs to be created for linear access, perhaps with hidden
links (images with ALT text in links) or a short list of links to index
the page.

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.

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.

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

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.

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.

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.

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

*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 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. The page, while totally plain, displays
fine with the default rendering of older that do not support CSS.
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.

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.

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

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.

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.

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.

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.

WE HAVE SOME BAD HABITS; GOOD LOOKS AND GOOD FUNCTIONALITY MAY BE DIFFERENT
A lot of problems are caused by habits we have acquired over the years
in attempting to give a more graphical shape to the Web, and we need to
start thinking anew about how to approach Web design for greater device
and browser independence. Remember, a consistent finding among usability
experts is what a user says about a design as far as "likeability" or
preference for the way it looks often does not correspond with the
design that works the best to get a task done or to get a message across
or to sell a product. And we all have a tendency to become attached to
what we feel is a good design, and to misapprehend the surface value of
a design for deeper levels of functionality .

I have some user style sheets I use to analyze Web pages for
accessibility problems. I often find that it is much easer to use a page
with these style sheets than the design the designer had, even though
from an artistic standpoint they make the page look terrible. Giving the
user the ability to change the appearance or non-visual rendition and
even the functionality of a page to great degree to suit preferences and
accommodate disabilities is a real challenge to a designer. Instead of
making a single good design for just normal folks, we need to make in
essence multiple designs for a single page, without having separate
pages for each design, and have that multifaceted design remain usable
and functionally intact through all those transformations.

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.

Terence de Giere
= EMAIL ADDRESS REMOVED =



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

From: Holly Marie
Date: Wed, Feb 27 2002 5:37AM
Subject: Re: Accessibility Observations
← Previous message | Next message →

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/

From: Terry Brainerd Chadwick
Date: Wed, Feb 27 2002 7:36AM
Subject: Re: Accessibility Observations
← Previous message | Next message →

Holly wrote:
>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.

Would you please provide a URL so we can see how you have accomplished this?

TIA,
Terry

Terry Brainerd Chadwick, InfoQuest! Information Services
mailto: = EMAIL ADDRESS REMOVED = 1-503-228-4023 http://www.tbchad.com
Accessibility isn't just the law; it's good business.
Optimizing Websites for Accessibility, Content, Search, & Usability


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

From: Holly Marie
Date: Wed, Feb 27 2002 10:56AM
Subject: Example [was]Re: Accessibility Observations
← Previous message | Next message →

----- Original Message -----
From: "Terry Brainerd Chadwick"

> Holly wrote:
> >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.
>
> Would you please provide a URL so we can see how you have accomplished
this?
>
> TIA,
> Terry


Hi Terry,
here you go.
I decided to toss together a short page with some anchor links and
absolute positioning. I left the font sizing default to browser and only
sized the Hx to 1.1 and 1.3 ems....

other wise, I believe you will find this page degrades fine to text
only, works on all browsers, and displays fine for visual. the colors
might not be your favorite, but those were also chosen with Color
Viewing difficulties in mind and the colors were piced from charts with
this also in mind.

A page does not have to be boring or lack graphics for design in order
to be Accessible. As a matter of fact, the colors and or graphics can
make the page more interesting or accessible for those that need these
items.

XHTML Strict and CSS 2 can both validate error free and warning free and
display across browsers as well as text only and in lynx viewers, too.
Style sheets off, does not destroy the message or content either.

page was checked at the links to the w3.org HTML/XHTML validator, and
also at the CSS validator.
The page was also checked at http://www.visicheck.com for color
blindness features.
The page was also taken to http://www.delorie.com and put in the
backwards compatibility viewer and had the style sheets turned off and
the images turned off.... and then at delorie it was put through the
lynx viewer and seems ok.

The only thing I did not have a chance to check was the speach browser
or reader mode, but I have a feeling this will work there also. My title
tagging and alt tagging might not be especially wonderful or content
perfect, but the idea works and the page should work just fine.

Let me know if you hit any problem areas with this particular page, as I
have been using a free tool to layout an absolute positioned page that I
found at the W3.org style news section on new tools to use.

holly

URL : http://www.qexo.com/access.html

the links to the W3 validators for this page are at the bottom of the
content section ...



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

From: Holly Marie
Date: Wed, Feb 27 2002 11:26AM
Subject: Re: Example [was]Re: Accessibility Observations
← Previous message | Next message →

----- Original Message -----
From: "Holly Marie"

> URL : http://www.qexo.com/access.html
>
> the links to the W3 validators for this page are at the bottom of the
> content section ...

There are no tables or deprecated codes or tags in the page.[xhtml
strict and css2 instead of tables is used]
There are two images, one repeating background image in the body
CSS[orange and yellow grid image]
The image on top of that image and under the links is a graphic I made
quickly in PSP, and displays under the link layer and over the bg image
layer upper right corner.

This is what I tested the page on:

Win 2000 here, and this is the list of browsers it works fine on:
K-Meleon - displays well
Mozilla 0.9.8 - displays well
Opera 5.01 - displays well
IE 5.5 - displays well
NN4.78 - displays fine, links all work, including anchors.
NN6.2 - displays well
Lynx 2.7.1 - content displays fine and in clear order.

Delorie Web Page Backward Compatibility Viewer is here:
remember you can turn off and on many different things, like tables,
images, scripts, css to view a page in any combination or turn it all
off and see how the page renders.[in opera you can do some similar
things]
http://www.delorie.com/web/wpbcv.html

For Lynx, I used theirs until I get one installed - the version they
have is older [ 2.7.1 ]:
http://www.delorie.com/web/lynxview.html

So, my thoughts. Layout of a page with CSS2 and XHTML strict works well
enough in all browsers in this case, and also degrades well to CSS
style - Less modes and text only lynx.

and enough of it works to use it now.

holly




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

From: Holly Marie
Date: Wed, Feb 27 2002 11:41AM
Subject: Correction - URL Re: Example [was]Re: Accessibility Observations
← Previous message | Next message →

From: "Holly Marie"

> The page was also checked at http://www.visicheck.com for color
> blindness features.

that should be http://www.vischeck.com
i keep wanting to add an i in there, heh

sorry

holly



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

From: Mark Rew
Date: Wed, Feb 27 2002 12:10PM
Subject: Re: Example [was]Re: Accessibility Observations
← Previous message | No next message

Holly,

I quickly looked at the page with Jaws 4.0 and found it reads well. Also, I
found the page quick and easy to navigate.

Mark
----- Original Message -----
From: "Holly Marie" < = EMAIL ADDRESS REMOVED = >
To: < = EMAIL ADDRESS REMOVED = >
Sent: Wednesday, February 27, 2002 12:56 PM
Subject: Example [was]Re: Accessibility Observations


>
> ----- Original Message -----
> From: "Terry Brainerd Chadwick"
>
> > Holly wrote:
> > >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.
> >
> > Would you please provide a URL so we can see how you have accomplished
> this?
> >
> > TIA,
> > Terry
>
>
> Hi Terry,
> here you go.
> I decided to toss together a short page with some anchor links and
> absolute positioning. I left the font sizing default to browser and only
> sized the Hx to 1.1 and 1.3 ems....
>
> other wise, I believe you will find this page degrades fine to text
> only, works on all browsers, and displays fine for visual. the colors
> might not be your favorite, but those were also chosen with Color
> Viewing difficulties in mind and the colors were piced from charts with
> this also in mind.
>
> A page does not have to be boring or lack graphics for design in order
> to be Accessible. As a matter of fact, the colors and or graphics can
> make the page more interesting or accessible for those that need these
> items.
>
> XHTML Strict and CSS 2 can both validate error free and warning free and
> display across browsers as well as text only and in lynx viewers, too.
> Style sheets off, does not destroy the message or content either.
>
> page was checked at the links to the w3.org HTML/XHTML validator, and
> also at the CSS validator.
> The page was also checked at http://www.visicheck.com for color
> blindness features.
> The page was also taken to http://www.delorie.com and put in the
> backwards compatibility viewer and had the style sheets turned off and
> the images turned off.... and then at delorie it was put through the
> lynx viewer and seems ok.
>
> The only thing I did not have a chance to check was the speach browser
> or reader mode, but I have a feeling this will work there also. My title
> tagging and alt tagging might not be especially wonderful or content
> perfect, but the idea works and the page should work just fine.
>
> Let me know if you hit any problem areas with this particular page, as I
> have been using a free tool to layout an absolute positioned page that I
> found at the W3.org style news section on new tools to use.
>
> holly
>
> URL : http://www.qexo.com/access.html
>
> the links to the W3 validators for this page are at the bottom of the
> content section ...
>
>
>
> ----
> To subscribe, unsubscribe, or view list archives,
> visit http://www.webaim.org/discussion/
>
>


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