WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Off-left vs. block/none oddity.

for

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

From: Christian Heilmann
Date: Fri, Feb 03 2006 7:30AM
Subject: Off-left vs. block/none oddity.
No previous message | Next message →

I did a demo of a Outlook style panel for a friend yesterday:
http://www.icant.co.uk/sandbox/dom-panel-bar/

Now, normally I am advocating and using the off-left technique for
hiding and showing elements, but as I was lazy in this case I used
display block and none in JavaScript instead.

Funnily enough, this seems to have made it a lot easier to use the
menu with a keyboard now as the hidden links don't show up in the tab
order unless you activate one of the parent links.

The question now is how screen readers deal with the activation and
navigation in it. If that is fine, I think it is a more obvious choice
for JavaScript driven menus to go the block/none way - pending you
don't hide the elements via CSS from the beginning.

Thoughts?

--
Chris Heilmann
Blog: http://www.wait-till-i.com
Writing: http://icant.co.uk/
Binaries: http://www.onlinetools.org/




From: pixeldiva
Date: Fri, Feb 03 2006 7:45AM
Subject: Re: Off-left vs. block/none oddity.
← Previous message | Next message →

On 03/02/06, Christian Heilmann < = EMAIL ADDRESS REMOVED = > wrote:
> The question now is how screen readers deal with the activation and
> navigation in it. If that is fine, I think it is a more obvious choice
> for JavaScript driven menus to go the block/none way - pending you
> don't hide the elements via CSS from the beginning.

The trouble is that more screen readers these days (specifically JAWS
springs to mind, but there are others) are parsing CSS and so if you
use display: none then it doesn't get read out at all.

There's a chart at
http://css-discuss.incutio.com/?page=ScreenreaderVisibility (which you
probably already know about, and if so, I apologise) with testing for
both display: none and visibility: hidden, but screen readers have
moved on a bit since that was done. I tend to take the view that it's
not worth the risk both now and in the future.

--
Ann
http://www.pixeldiva.co.uk




From: Christian Heilmann
Date: Fri, Feb 03 2006 8:00AM
Subject: Re: Off-left vs. block/none oddity.
← Previous message | Next message →

> > The question now is how screen readers deal with the activation and
> > navigation in it. If that is fine, I think it is a more obvious choice
> > for JavaScript driven menus to go the block/none way - pending you
> > don't hide the elements via CSS from the beginning.
>
> The trouble is that more screen readers these days (specifically JAWS
> springs to mind, but there are others) are parsing CSS and so if you
> use display: none then it doesn't get read out at all.

I know, hence the "pending you don't hide the elements via CSS from
the beginning." :-)

Hiding things via CSS and hoping JavaScript will be available to show
them is bad development practice, as you rely on two technologies that
might not be available.

The screen reader question might have been not properly formed by me,
hence the misunderstanding. I am not hiding anything with CSS but only
when JS is available - actually I don't even provide any links to show
and hide the sub sections when JS is turned off.

The scenario I am interested in is screen reader + JS enabled.

In other scripts I used the off-left technique - as advertised by Joe
Clark and the research you provided the link to. These had the problem
that I had to tab through each link as a keyboard user. By hiding the
elments _in JavaScript_ via block/none I don't have that problem.

I have Jaws at home, will give it a spin later.

--
Chris Heilmann
Blog: http://www.wait-till-i.com
Writing: http://icant.co.uk/
Binaries: http://www.onlinetools.org/




From: pixeldiva
Date: Fri, Feb 03 2006 8:15AM
Subject: Re: Off-left vs. block/none oddity.
← Previous message | Next message →

On 03/02/06, Christian Heilmann < = EMAIL ADDRESS REMOVED = > wrote:
> Hiding things via CSS and hoping JavaScript will be available to show
> them is bad development practice, as you rely on two technologies that
> might not be available.

Exactly, which was what slightly confused me. Might just be me reading
it wrong (have a bad head cold and should probably stay away from
email :))

> The screen reader question might have been not properly formed by me,
> hence the misunderstanding. I am not hiding anything with CSS but only
> when JS is available - actually I don't even provide any links to show
> and hide the sub sections when JS is turned off.

So, let me get this straight:

When JS is off and CSS is off, everything is shown?

When JS is off and CSS is on, what happens?

When JS is on and CSS is off (less common scenario, but possible), what happens?

> The scenario I am interested in is screen reader + JS enabled.

I've forwarded it to three experienced screen reader users to give it
a go. Will let you know what they come back with.

--
Ann
http://www.pixeldiva.co.uk




From: Kynn Bartlett
Date: Fri, Feb 03 2006 8:30AM
Subject: Re: Off-left vs. block/none oddity.
← Previous message | Next message →

Don't most hacks like this imply some sort of basic problem in the
underlying structure of your content presentation?

I'm just sayin'...

--Kynn




From: Andrew Kirkpatrick
Date: Fri, Feb 03 2006 8:45AM
Subject: RE: Off-left vs. block/none oddity.
← Previous message | Next message →

I also have a chart that looks at this:
http://www.webaccessibility.info/lab/displaytest.html

AWK

>

From: Kynn Bartlett
Date: Fri, Feb 03 2006 9:00AM
Subject: Re: Off-left vs. block/none oddity.
← Previous message | Next message →

On 2/3/06, Patrick Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> > Don't most hacks like this imply some sort of basic problem in the
> > underlying structure of your content presentation?

> Not necessarily. The structure here is fine, but the usability may not
> be ideal. Not strictly a hack, but an enhancement?

I suppose.

Should browsers allow access to content which is placed 990 pixels
off-screen somewhere? Why or why not? It seems to me that whenever
you have to resort to something like that, it is a hack rather than a
feature.

*shrug* But, hey, if works for you, by all means. Just hope that it
continues to work well, which is one of the big problems with the
overly complex schemes we sometimes see in Web design. :)

--Kynn




From: Christian Heilmann
Date: Fri, Feb 03 2006 9:15AM
Subject: Re: Off-left vs. block/none oddity.
← Previous message | Next message →

> > Don't most hacks like this imply some sort of basic problem in the
> > underlying structure of your content presentation?

It would help to tell us what you mean by "hack"?

> Not necessarily. The structure here is fine, but the usability may not
> be ideal. Not strictly a hack, but an enhancement?

That is the idea. Ever since the first DHTML multi level dropdown menu
popped up on the web clients go apesh^H^H^H^H^H^H very excited about
this prospect. We all know it is not a need to offer that much
navigation on every page, but go and try to tell clients that. Reloads
seem to be the most scary thing on this planet, smothering content in
300 links / page is OK though :-)

--
Chris Heilmann
Blog: http://www.wait-till-i.com
Writing: http://icant.co.uk/
Binaries: http://www.onlinetools.org/




From: Christian Heilmann
Date: Fri, Feb 03 2006 9:30AM
Subject: Re: Off-left vs. block/none oddity.
← Previous message | Next message →

> > It would help to tell us what you mean by "hack"?
>
> Using standard markup and styles to produce something generally
> desirable in a way which was not specifically intended nor even
> implied in the specification.

Ah. Well, if we only went for what is in the specs, and how it is
meant to be, I could use inline onclicks and onkeypress together and
have an accessible site. However, that would mean that Firefox users
would get onkeypress functionality when they tab over the element,
which is not good. It would also mean that maintainability of the site
is very much under par. If I followed the 508 to the dot I could even
use javascript: links, as they "are supported by assistive
technology".

You are right though, hiding and showing things is a tempting but
dangerous toy. I said that some years ago and still mean it.
http://icant.co.uk/forreview/dynamicelements/

> > > Not necessarily. The structure here is fine, but the usability may not
> > > be ideal. Not strictly a hack, but an enhancement?
>
> > That is the idea. Ever since the first DHTML multi level dropdown menu
> > popped up on the web clients go apesh^H^H^H^H^H^H very excited about
> > this prospect.
>
> It's nice that Web clients want it. Web clients are often idiots,
> though, and whatever they go apeshit over may not be best practices,
> unless by "best practices" you mean "any hack to earn a buck."

Yes, much like the pointy haired boss in Dilbert, and who does the
business decisions and hires and fires people?

> > We all know it is not a need to offer that much
> > navigation on every page, but go and try to tell clients that.
> Why not tell them that?
> What do users think?
> What do your user studies show you, that you can then take to your clients?
> I mean, if the users are for it, that's one thing, but you're not
> arguing here that users are demanding menus or hidden text; you're
> arguing that clients want it. You would be arguing on stronger
> grounds if you had any sort of evidence to offer that this is good for
> the Web. (And by good for the Web, I mean good for the Web user.)

Yes, I know all that - but have you ever talked to an enterprise
level client or a client on a fixed price budget of which 50% were
already spent on a CMS that doesn't do its job? I am the UCD
evangelist here, and try to sell proper usability tests and iterations
on every project. So far I managed that with 3 of 14 clients as on the
first glance, it is an overhead cost without immediate results. Don't
get me wrong, I know it is not, I am just repeating what an
accountancy person told me.

We will go nowhere if we don't hold back from time to time, step down
from the soap box and get our hands dirty dealing with real
development life problems.

It is no use to ditch an interface because it is sub-optimal when it
comes out of the box of the

From: Christian Heilmann
Date: Fri, Feb 03 2006 9:45AM
Subject: Re: Off-left vs. block/none oddity.
← Previous message | Next message →

> When JS is off and CSS is off, everything is shown?
> When JS is off and CSS is on, what happens?

^ both the same. Well, almost. You can define a basic style for the
non-javaScript version. JS adds a special class to the list to allow
for a style that only gets applied when JS is available.

that way you can style

#nav { } /* non - JavaScript */
#nav.panel { } /* JavaScript */

> When JS is on and CSS is off (less common scenario, but possible), what happens?

The script still hides and shows the sub-sections as I write directly
to the DOM style attribute instead of applying a class.

> > The scenario I am interested in is screen reader + JS enabled.
>
> I've forwarded it to three experienced screen reader users to give it
> a go. Will let you know what they come back with.

Good. Next geek dinner come around again and you get a drink on me. Or
next time I cycle to king's cross.


--
Chris Heilmann
Blog: http://www.wait-till-i.com
Writing: http://icant.co.uk/
Binaries: http://www.onlinetools.org/




From: Kynn Bartlett
Date: Fri, Feb 03 2006 10:00AM
Subject: Re: Off-left vs. block/none oddity.
← Previous message | Next message →

On 2/3/06, Christian Heilmann < = EMAIL ADDRESS REMOVED = > wrote:
> > > It would help to tell us what you mean by "hack"?
> > Using standard markup and styles to produce something generally
> > desirable in a way which was not specifically intended nor even
> > implied in the specification.

> Ah. Well, if we only went for what is in the specs, and how it is
> meant to be, I could use inline onclicks and onkeypress together and
> have an accessible site. However, that would mean that Firefox users
> would get onkeypress functionality when they tab over the element,
> which is not good. It would also mean that maintainability of the site
> is very much under par. If I followed the 508 to the dot I could even
> use javascript: links, as they "are supported by assistive
> technology".

Now you're straw-manning me here. Did I say that the spec is always
sufficient? No, I defined "hack" for you, because apparently you Have
Never Encountered The Word And Needed It Defined.

(Which, of course, is false -- you know exactly what I meant, and were
feigning ignorance as a rhetorical tactic.)

> You are right though, hiding and showing things is a tempting but
> dangerous toy. I said that some years ago and still mean it.
> http://icant.co.uk/forreview/dynamicelements/

Oh, so you agree with me, but you're still right because your clients
are idiots.

> > It's nice that Web clients want it. Web clients are often idiots,
> > though, and whatever they go apeshit over may not be best practices,
> > unless by "best practices" you mean "any hack to earn a buck."

> Yes, much like the pointy haired boss in Dilbert, and who does the
> business decisions and hires and fires people?

So if your client said "fuck the blindies, I want an inaccessible
site!" you'd make it?

> Yes, I know all that - but have you ever talked to an enterprise
> level client or a client on a fixed price budget [...]

Blah blah blah. Okay, so inaccessibility is fine if the client wants
it. By all means, if you are making money by selling out Web users,
go for it!

You'll be rich!

Don't expect me to automatically respect you, and insulate you from
criticism of poor techniques, though. Just because you've sold out,
that doesn't make you right.

> We will go nowhere if we don't hold back from time to time, step down
> from the soap box and get our hands dirty dealing with real
> development life problems.

*rolls eyes*

> Maybe we should talk
> to the vendors of development frameworks and help them with our
> knowledge to make their out-of-the-box solutions better?

Maybe? Isn't that a given?

> Last year I published an article on why clients don't care about
> accessibility [1] and all of these reasons are the ones we have to
> tackle, not point at the specs or best practices and repeat truths
> that the user is the most important thing.

And your way of tackling it is to bow to the people who pay you.
That's fine for you, but not everyone here is as mercenary, so I don't
understand why you're fighting against people who you admit are
actually right and correct.

You know that what you're promoting -- client appeasement over end
user accessibility and usability -- is wrong. Why are you defending
it?

> You pose a lot of good solutions right now, do you have figures to
> back them up?

Me personally? No.

Should the industry be developing these? Hell, I thought someone was.
What have you people been doing the last few years?

> > You have weird clients.
>

From: Patrick Lauke
Date: Fri, Feb 03 2006 10:15AM
Subject: RE: Off-left vs. block/none oddity.
← Previous message | Next message →

> Kynn Bartlett

> Don't most hacks like this imply some sort of basic problem in the
> underlying structure of your content presentation?

Not necessarily. The structure here is fine, but the usability may not
be ideal. Not strictly a hack, but an enhancement?

P
________________________________
Patrick H. Lauke
Web Editor / University of Salford
http://www.salford.ac.uk
________________________________
Web Standards Project (WaSP) Accessibility Task Force
http://webstandards.org/
________________________________




From: Kynn Bartlett
Date: Fri, Feb 03 2006 10:30AM
Subject: Re: Off-left vs. block/none oddity.
← Previous message | Next message →

On 2/3/06, Christian Heilmann < = EMAIL ADDRESS REMOVED = > wrote:
> > > Don't most hacks like this imply some sort of basic problem in the
> > > underlying structure of your content presentation?

> It would help to tell us what you mean by "hack"?

Using standard markup and styles to produce something generally
desirable in a way which was not specifically intended nor even
implied in the specification.

For example, hiding visibility by placing something way out in left
field (literally) as a way of making some content available to some
users, and not available to other users. Or, using positioning styles
to temporarily hide something from view, which is "by spec" meant to
be done in a way that doesn't involve positioning.

> > Not necessarily. The structure here is fine, but the usability may not
> > be ideal. Not strictly a hack, but an enhancement?

> That is the idea. Ever since the first DHTML multi level dropdown menu
> popped up on the web clients go apesh^H^H^H^H^H^H very excited about
> this prospect.

It's nice that Web clients want it. Web clients are often idiots,
though, and whatever they go apeshit over may not be best practices,
unless by "best practices" you mean "any hack to earn a buck."

> We all know it is not a need to offer that much
> navigation on every page, but go and try to tell clients that.

Why not tell them that?

What do users think?

What do your user studies show you, that you can then take to your clients?

I mean, if the users are for it, that's one thing, but you're not
arguing here that users are demanding menus or hidden text; you're
arguing that clients want it. You would be arguing on stronger
grounds if you had any sort of evidence to offer that this is good for
the Web. (And by good for the Web, I mean good for the Web user.)

(There may very well be an argument that users want these menus; I
don't know. Hierarchical menus have a problem of hiding links that
could or should be obvious at various times; it takes a lot of work
and a lot of testing to create a particularly well-done hierarchical,
collapsing menu user interface.)

> Reloads
> seem to be the most scary thing on this planet, smothering content in
> 300 links / page is OK though :-)

You have weird clients.

--Kynn




From: Christian Heilmann
Date: Fri, Feb 03 2006 11:15AM
Subject: Re: Off-left vs. block/none oddity.
← Previous message | Next message →

Ok, this is getting off-topic and I am not here to be personally
insulted and marked as a traitor to the accessibility cause. You don't
know me and obviously didn't grasp any of the questions I had. I
_want_ to get UCD and accessibility out into the big money market, I
_want_ to have a budget on every project I start that covers testing
and compliance. Arrogance and Ignorance will not get us there.

Nothing of what you said about me or my company was true or even
partly true and if that is a general notion I really begin to wonder
why I even bother trying to talk to enterprise level clients about
these issues or tell developers who consider a blog or a 10 page
brochureware site that it will be hard to implement the same in a
large web site that has been around for years and has 300 different
people contributing to it.

Advocating web standards and accessibility so far gave me the notion
in the company of the stick in the mud preventing the design team to
go nuts and do whatever the client marketing team wanted to have
implemenented. I spent hours in meetings with upper management to not
do a certain kind of work as it is simply shooting ourselves in the
foot when there will be legal repercussions because we did not deliver
an accessible product. I spent a lot of my freetime talking to other
developers and evangelising the cause at trainings in .NET
technologies and technical abominations (CMS) delivering table layouts
and considering accessibility compliance adding a spacer gif as a skip
link.

Maybe you are right, and I should just sell out and shut down all my
free scripts, articles and tell the likes of evolt, digital web,
alistapart and sitepoint to show me money for my contributions. Maybe
I should just go for the MCSE or sell a CMS as AAA compliant although
I know it isn't.

If you look through the archives of this mailing list you'll find that
I had a lot of discussions where I showed your point of view -
defending it as vehemently as you do - and all it got us to was
bitching and sometimes even getting moderated.

I sincerely think that there is two sides to every conversation. There
is your assumption of what the other person thinks and there is what
he really thinks. In an impersonal media like email (where most human
conversation is not given - body language, tone of voice...) you can
easily start to insult or hurt people - sometimes even without wanting
to.




From: Jared Smith
Date: Sat, Feb 04 2006 8:45AM
Subject: Re: Off-left vs. block/none oddity.
← Previous message | Next message →

pixeldiva wrote:
> The trouble is that more screen readers these days (specifically JAWS
> springs to mind, but there are others) are parsing CSS and so if you
> use display: none then it doesn't get read out at all.

The next version of JAWS will (at least according to Freedom Scientific)
have its own DOM interpreting engine separate from IE. It will reportedly
fix many of these inconsistencies, plus allow developers to manipulate
elements with DOM, DHTML, etc. and still have them be (theoretically)
accessible. It will probably also mean that lots of things will change and
we'll have a new set of screen reader inconsistencies to deal with.

Jared Smith
WebAIM.org





From: Steven Faulkner
Date: Sun, Feb 05 2006 6:00PM
Subject: RE: Off-left vs. block/none oddity.
← Previous message | Next message →

Can anyone suggest why the CSS z-index property could not used to
position content behind other content (as against pushing content off
screen), so it is effectively hidden from visual presentation, but
available to screen readers (as the z-index is not interpreted by screen
readers as far as i know).

Here is a (not particularly good) example of this method I experimented
with a while back, using it to visually present a number of simple data
tables as one complex table.
http://www.nils.org.au/ais/table.html


with regards


Steven Faulkner
Web Accessibility Consultant
vision australia - information & library service
454 Glenferrie Road
Kooyong Victoria 3144
Phone: (613) 9864 9281
Fax: (613) 9864 9210
Email: = EMAIL ADDRESS REMOVED =
www.accessibleinfo.org.au | www.wat-c.org

Download the Web Accessibility Toolbar
[http://www.visionaustralia.org.au/ais/toolbar/]

Vision Australia was formed through the merger of the Royal Blind
Society
NSW, the Royal Victorian Institute for the Blind, Vision Australia
Foundation and the National Information & Library Service.
ABN: 67 108 391 831 ACN: 108 391 831



>

From: Robinson, Norman B - Washington, DC
Date: Mon, Feb 06 2006 8:45AM
Subject: RE: Off-left vs. block/none oddity.
← Previous message | No next message

Yet another reason to use consistent, standards based implementations.
Although the vendor mentioned makes a great product, it is _software_
and as such, has defects. I know this argument isn't much different than
how designers and content developers work around defects in the myriad
of browsers on different operating systems, but we shouldn't be building
and indexing every known set of defects.

Extending and reframing an argument on this thread, I'd say that this
also addresses user accessibility and usability by supporting standard
based approaches. It makes it easier to explain to your client that
valid code, standards, open standards (technologies available to
everyone without proprietary lock-in), and accessible implementations
are the proper way to develop. Screen readers should thus be able to
know what technologies to support and not waste time on work arounds for
proprietary solutions.


Regards,


Norman