CSS and Doctypes

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

CSS and Doctypes

mozilla accessibility
Sometimes, its helpful to annotate pages with content that should not be
visible, but should be voiced by screen readers.

If screen readers and browsers dealt with aural CSS, then I'm sure this
could be done correctly.

The technique I've used for this is to attach a class, call it aural, to the
elements I want to hide from view and want voiced by the screen reader. Then
I use the following CSS:

.aural {
position: absolute;
top: -9999;
}

When I play with things like this, I am usually lazy and never include a
doctype. Well, today I was playing around and noticed that if you use a
valid doctype (I've tried xhtml and html4, both strict and transitional),
this technique does not work, either in IE or Firefox 3.

I assume because this is somehow not valid CSS, that this fails unless the
browser is in querks mode (missing doctype).  Can anyone in the know explain
this further? Am I missing something?

In my opinion, I think this is a nice technique, and one which should be
allowed, at least perhaps in the transitional modes.

Thanx in advance for any info.
-- Rich

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: CSS and Doctypes

James Craig-4
Rich Caloggero wrote:

> .aural {
> position: absolute;
> top: -9999;
> }
>
> When I play with things like this, I am usually lazy and never  
> include a
> doctype. Well, today I was playing around and noticed that if you  
> use a
> valid doctype (I've tried xhtml and html4, both strict and  
> transitional),
> this technique does not work, either in IE or Firefox 3.
>
> I assume because this is somehow not valid CSS, that this fails  
> unless the
> browser is in querks mode (missing doctype).  Can anyone in the know  
> explain
> this further? Am I missing something?

You're missing the size unit. You need -9999px not -9999. The only  
valid unit-less number is zero. The W3C CSS Validator will catch that  
error for you.

Also, you should know that this technique caused a peculiarity in  
VoiceOver in Group Navigation mode. Basically it renders the CSS, and  
reads those separately because that are positioned separately "on the  
screen." It works as intended if you're in the default DOM Navigation  
mode.

Cheers,
James

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: CSS and Doctypes

bhawkeslewis
In reply to this post by mozilla accessibility
Rich Caloggero wrote:

> The technique I've used for this is to attach a class, call it aural, to the
> elements I want to hide from view and want voiced by the screen reader. Then
> I use the following CSS:
>
> .aural {
> position: absolute;
> top: -9999;
> }
>
> When I play with things like this, I am usually lazy and never include a
> doctype. Well, today I was playing around and noticed that if you use a
> valid doctype (I've tried xhtml and html4, both strict and transitional),
> this technique does not work, either in IE or Firefox 3.

AFAIK this works fine. Do you have a testcase to demonstrate yor problem?

> I assume because this is somehow not valid CSS, that this fails unless the
> browser is in querks mode (missing doctype).  Can anyone in the know explain
> this further? Am I missing something?

A missing doctype is not the only way to trigger quirks.

--
Benjamin Hawkes-Lewis


_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: CSS and Doctypes

Gregory J. Rosmaita
In reply to this post by mozilla accessibility
aloha, rich!

are you thinking of something along the lines of WCAG2 Technique
C7:

http://www.w3.org/TR/WCAG20-TECHS/C7.html
http://www.w3.org/TR/2007/WD-UNDERSTANDING-WCAG20-20071211/navigation-
mechanisms-refs.html

which details a repair technique which enables a user to contextualize
and fully understand the meaning and target of repetitive hyperlink
test.  The result would be individualized index items, rather than merely
a repetitious and uninformative listing of links by section/chapter
number ONLY, thus making it possible for the non-visual user to utilize
the index.  This repair technique also has the advantage of
individualizing each hyperlink when the document's hyperlinks are listed
in a list of links, or when one is aurally or tactilely experiencing the
index.

using the repair to provide extended contextualizing information in
terse, otherwise repetitive, hyperlinks involves:

1) the following addition to the document's default stylesheet

a span { height: 1px; width: 1px; position: absolute;
   overflow: hidden; top: -10px; }

2) the following addition to the html/xhtml:

<!-- begin example -->
<a href="news-2008-02-28"
>Read More<span> about Our Leap Year Specials</span></a>
<!--  ... -->
<a href="news-2008-02-14">Read More<span> about the release of Cupid,
version 6.9</span></a>
<!--  ... -->
<a href="news-2008-01-01">Read More<span> about our Initiatives for
2008</span></a>
<!-- end example -->

note that whilst the WCAG 2.0 technique applies specifically to providing
extended contextual information to the user; moreover, it is a technique
that works in FF2, FF3 and IE7 - check, for example:

http://www.hicom.net/~oedipus/books/libraries.html

it can also be used to add "invisible text" -- this is the ONLY legitimate
way of hiding extended contextual information in "plain sight" -- as
confirmed by the editors and chairs of the CSS working group,

display:none

and

visibility:hidden

apply to ALL media types, so their use SHOULD result in a perceptual
black hole for every media type (aural, visual, print) -- the only way
to hide text in the visual canvas is to use the overflow property in
CSS

note that this is the 21st century version of using the infamous clear
pixel gif to add information to the aural or non-stylesheet capable
)text-only) user agents through the "alt" attribute -- with the advantage
that (a) it uses CSS and (b) through the use of selectors, items can
be exposed or hidden from the visual canvas in response to user action
or an associated scripted event...

i hope this helps -- and more importantly answers the question you
posed,

gregory.


---------- Original Message -----------
From: Rich Caloggero <[hidden email]>
To: [hidden email]
Sent: Thu, 28 Feb 2008 17:17:26 -0500
Subject: CSS and Doctypes

> Sometimes, its helpful to annotate pages with content that
> should not be visible, but should be voiced by screen readers.
>
> If screen readers and browsers dealt with aural CSS, then I'm
> sure this could be done correctly.
>
> The technique I've used for this is to attach a class, call it
> aural, to the elements I want to hide from view and want voiced
> by the screen reader. Then I use the following CSS:
>
> .aural {
> position: absolute;
> top: -9999;
> }
>
> When I play with things like this, I am usually lazy and never
> include a doctype. Well, today I was playing around and noticed
> that if you use a valid doctype (I've tried xhtml and html4,
> both strict and transitional), this technique does not work,
> either in IE or Firefox 3.
>
> I assume because this is somehow not valid CSS, that this fails
> unless the browser is in querks mode (missing doctype).  Can
> anyone in the know explain this further? Am I missing something?
>
> In my opinion, I think this is a nice technique, and one which
> should be allowed, at least perhaps in the transitional modes.
>
> Thanx in advance for any info.
> -- Rich
>
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility
------- End of Original Message -------

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: CSS and Doctypes

mozilla accessibility
In reply to this post by James Craig-4
Hmm, I wasn't able to get this to work, even by adding units (i.e. px).  The
only way this worked if a valid doctype was given was if I included the
overflow:hidden

I need to try this with VoiceOver.  DOes anyone know exactly how group
navigation in VoiceOver works? What constitutes a group - a top-level div?
Are they looking at actual screen position in order to group elements or
just the DOM?

Thanx in advance.
-- Rich

----- Original Message -----
From: "James Craig" <[hidden email]>
To: "Rich Caloggero" <[hidden email]>
Cc: <[hidden email]>
Sent: Thursday, February 28, 2008 7:20 PM
Subject: Re: CSS and Doctypes


Rich Caloggero wrote:

> .aural {
> position: absolute;
> top: -9999;
> }
>
> When I play with things like this, I am usually lazy and never
> include a
> doctype. Well, today I was playing around and noticed that if you
> use a
> valid doctype (I've tried xhtml and html4, both strict and
> transitional),
> this technique does not work, either in IE or Firefox 3.
>
> I assume because this is somehow not valid CSS, that this fails
> unless the
> browser is in querks mode (missing doctype).  Can anyone in the know
> explain
> this further? Am I missing something?

You're missing the size unit. You need -9999px not -9999. The only
valid unit-less number is zero. The W3C CSS Validator will catch that
error for you.

Also, you should know that this technique caused a peculiarity in
VoiceOver in Group Navigation mode. Basically it renders the CSS, and
reads those separately because that are positioned separately "on the
screen." It works as intended if you're in the default DOM Navigation
mode.

Cheers,
James

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: CSS and Doctypes

James Craig-4
Rich Caloggero wrote:

> I need to try this with VoiceOver.  DOes anyone know exactly how group
> navigation in VoiceOver works? What constitutes a group - a top-
> level div?
> Are they looking at actual screen position in order to group  
> elements or
> just the DOM?

Disclaimer: I'm not on the VoiceOver team, nor am I in Apple  
Marketing, but my understanding of DOM vs Group Navigation follows.

DOM Navigation, the default, goes in source code order, like most  
screen readers and speech browsers have until this point. Navigation  
by headings, links, or form elements can provide shortcuts, but the  
default linear navigation just goes through elements in source code  
order.

Group Navigation uses the WebKit-rendered "HTML Content" from a web  
view, which pays attention to CSS Layout. This means that items  
rendered in close visual proximity will be spoken together, regardless  
of their source code order. It also means that the speech doesn't  
pause between insignificant DOM elements like span tags. I'm not sure  
about the technical specifics of how group proximity is determined.  
Navigation by headings, links, or form elements still works as expected.

The reason I mentioned it is because the common absolute-position-off-
screen trick behaves undesirably in Group Navigation mode. All  
elements positioned -9999px off screen are positioned in close  
proximity to each other, so they are all spoken as part of the same  
group. It's just something to watch out for when recommending that CSS  
workaround.

For what it's worth, all the VoiceOver users I've talked to use the  
default DOM Navigation.

James

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

RE: CSS and Doctypes

Sina Bahram
What about Lenora?

Take care,
Sina

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of James
Craig
Sent: Friday, February 29, 2008 3:45 PM
To: [hidden email]
Cc: Rich Caloggero
Subject: Re: CSS and Doctypes

Rich Caloggero wrote:

> I need to try this with VoiceOver.  DOes anyone know exactly how group
> navigation in VoiceOver works? What constitutes a group - a top- level
> div?
> Are they looking at actual screen position in order to group elements
> or just the DOM?

Disclaimer: I'm not on the VoiceOver team, nor am I in Apple Marketing, but
my understanding of DOM vs Group Navigation follows.

DOM Navigation, the default, goes in source code order, like most screen
readers and speech browsers have until this point. Navigation by headings,
links, or form elements can provide shortcuts, but the default linear
navigation just goes through elements in source code order.

Group Navigation uses the WebKit-rendered "HTML Content" from a web view,
which pays attention to CSS Layout. This means that items rendered in close
visual proximity will be spoken together, regardless of their source code
order. It also means that the speech doesn't pause between insignificant DOM
elements like span tags. I'm not sure about the technical specifics of how
group proximity is determined.  
Navigation by headings, links, or form elements still works as expected.

The reason I mentioned it is because the common absolute-position-off-
screen trick behaves undesirably in Group Navigation mode. All elements
positioned -9999px off screen are positioned in close proximity to each
other, so they are all spoken as part of the same group. It's just something
to watch out for when recommending that CSS workaround.

For what it's worth, all the VoiceOver users I've talked to use the default
DOM Navigation.

James

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility