WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Site Check

for

From: Holly Marie
Date: Sep 6, 2003 1:05AM

From: "Cheryl D. Wise"

> You might want to take a look at the source ordered column layout at
> http://positioniseverything.net if that one doesn't suit maybe one of
the
> other column layouts he has will work.

I agree, this is another of those interesting CSS sites, and there are
several different items, though as he notes there are buggy behaviors
or outcomes with some.

I keep meaning to check which layout of his or on his site causes IE to
get very buggy. Actually the OS gets buggy when loading the page. It is
only one particular one, that I noticed. And it only happens when it is
loaded in IE and not in Moz or other browsers, I believe. It has
happened each time I loaded that particular CSS example. I checked the
source or CSS I thought, but not completely, and I was going to write
him, but something happened and I had to leave the desk. It was bad
enough that using WIN 2k, CTRL ALT DEL to force quit the IE browser was
not possible. What happened? The CSS on the page, and I did not see any
javascript involved, seized control of the mouse in such a way that one
could not move the mouse cursor anywhere by will or the functionality of
the mouse and its movement were shot. The cursor would move to odd
areas, the memory on the system would be used to the max[page caused a
memory link type situation], and changing focus onto other windows was
near impossible, because getting control back on the cursor via mouse or
keyboard was very hard. If lucky, focus off that page and onto another
window allowed the ability to force quit the IE instances through CTRL
ALT DEL. It would have been helpful to move the cursor to the [x] to
close the window, which would work if you could get it there. I wanted
to bookmark that page, or write it down and see if others had the same
problem.



[*] when working with positioning and or floats, there are times where
the CSS looks harmless enough and seems accessible by automated tests,
some manual checking etc... but many forget to try a page without a
mouse(in various browsers), or test these pages via a keyboard.

I feel keyboard accessibility may be as important as other access
issues. Think about the challenged user that works with sticky keys, a
mouth or puff stick, or a myriad of other options while working,
learning, or using the web. Navigating a web page or website is key. How
can such a user access content links if they cannot get past the
location bar, or past an area of links. And I am not talking about the
issue or problems with legacy NN and a keyboard with some designs, but I
am talking about other browsers, too... IE versions, newer Moz based
releases, etc... Users in wheel chairs, house bound, quadraplegics, a
variety of users with CP, stroke victims, or other mobility issues, may
use a computer for quite a few reasons from their home, school, or
office and for many reasons.

I found this problem is not limited to CSS layers, but also happens in
cases with some floats, or layouts.
I also found that there are times where CSS makes it very difficult for
a user to copy/paste a selected or desired area of text and may get
stuck copy/pasting a whole page of divs, because isolation or
highlighting of target areas is nearly impossible. [noticed with IE
browsers and some float divs situations]. There are also issues with
javascript and event handlers that include the mouse and need to be
checked or written in such a way that the keyboard works when the mouse
is not available.

Manual checks are important, automated tests or checks may not find
these issues, and testing a page for mouseless accessibility and tab
ability is also very important, in various browsers/versions, with CSS
loaded and not, etc. It is not enough to assume that a user has access
to all browsers and versions, or even IE. They may not use IE for
security purposes or other reasons. They may not have Javascript enabled
for the same reasons. And there are cases in which IE fails when using a
mouse and not.

One recent site with changes, poses some keyboard access problems,
though the site is written to standards, addresses accessibility, and
uses CSS. I found a variety of keyboard navigation issues while trying
to access the http://www.macromedia.com website on various browsers and
versions(I am not sure if this has been changed since last week). Check
behavior or outcomes while trying to tab into the page for a link in the
content, after the top menu area. In some cases one could not tab out of
the top menubar location area into the page at all[the top menubar area
remains a small loop of navigational choices). In other trials the top
menubar area does not seem available at all and in many cases the links
at the top menu area produce the same link location information for all
top menu bar area links in the status bar of the browser[does not change
for the top links]. This is important as users with non mouse navigation
may need to see that status bar to associate which link the keyboard has
focus on, or is set to follow, and even more important when there are no
visible(or barely visible) changes on the page as the focus on links
changes, [highlighting, outlines, etc]. The status bar may be another
useful way of knowing the link target to these users and naming those
link target files well, is helpful [home.html, contact.html, order.html
.. .etc.], being able to see those change correctly is also important.
Tool tips via title/link are not seen for links accessed via keyboard
and not mouse.

holly


> From: Ben Morrison
>
> On 5/9/03 12:33 pm, "Holly Marie" < <EMAIL REMOVED> > wrote:
>
> >
> > A nice advantage that CSS has over table layout for pages is the
> > ability to rearrange content for better readability or linearize the
> > delivery in optimal ways.] Tables are more or less fixed
sequentially
> > by the row by row, left to right delivery mode.
> >
> Yes that is my next priority. I was having problems with float left as
> opposed to floating right to re-order the content.
>
>
> ----
> To subscribe, unsubscribe, suspend, or view list archives,
> visit http://www.webaim.org/discussion/
>
>


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