E-mail List Archives

Search E-mail List Archives for

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

From: Bryan Garaventa
Date: Sat, Jan 07 2012 7:27PM
Subject: Interesting effect with CSS
No previous message | Next message →

I came a cross this the other day.

For a while I thought that using the CSS technique :after or :before would be useful for displaying content visually but hiding it from screen readers, such as adding a graphical arrow or plus/minus sign on a menu or similar like so:

li.treeitem:after {
content: '+';
}

Which is invisible in IE using JAWS and NVDA. However this actually is visible in both JAWS and NVDA using Firefox.

No idea if this is helpful or not, but I thought it was interesting.

Bryan

From: Jared Smith
Date: Sat, Jan 07 2012 8:36PM
Subject: Re: Interesting effect with CSS
← Previous message | Next message →

On Sat, Jan 7, 2012 at 7:28 PM, Bryan Garaventa
< = EMAIL ADDRESS REMOVED = > wrote:

> Which is invisible in IE using JAWS and NVDA. However this actually is visible in both JAWS and NVDA using Firefox.

Interesting. I'd think it would be preferable to have this CSS content
NOT read by any screen reader. If used correctly, CSS shouldn't be
used to present real content.

Jared

From: Patrick H. Lauke
Date: Sun, Jan 08 2012 4:18AM
Subject: Re: Interesting effect with CSS
← Previous message | Next message →

On 08/01/2012 03:37, Jared Smith wrote:
> On Sat, Jan 7, 2012 at 7:28 PM, Bryan Garaventa
> < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Which is invisible in IE using JAWS and NVDA. However this actually is visible in both JAWS and NVDA using Firefox.
>
> Interesting. I'd think it would be preferable to have this CSS content
> NOT read by any screen reader. If used correctly, CSS shouldn't be
> used to present real content.

I think that's one of those chicken and egg situations...if authors used
CSS the way it's meant, and in particular didn't use CSS content for
actual important content generation, then yes screenreaders should
ignore it. As there are probably enough cases where this isn't happening
(i.e. enough sites that do rely on CSS content for important content),
assistive technology had to adapt.

P
--
Patrick H. Lauke

From: Leif Halvard Silli
Date: Sun, Jan 08 2012 4:42AM
Subject: Re: Interesting effect with CSS
← Previous message | Next message →

Patrick H. Lauke, Sun, 08 Jan 2012 11:20:33 +0000:
> On 08/01/2012 03:37, Jared Smith wrote:
>> On Sat, Jan 7, 2012 at 7:28 PM, Bryan Garaventa wrote:
>>
>>> Which is invisible in IE using JAWS and NVDA. However this actually
>>> is visible in both JAWS and NVDA using Firefox.
>>
>> Interesting. I'd think it would be preferable to have this CSS content
>> NOT read by any screen reader. If used correctly, CSS shouldn't be
>> used to present real content.
>
> I think that's one of those chicken and egg situations...if authors used
> CSS the way it's meant, and in particular didn't use CSS content for
> actual important content generation, then yes screenreaders should
> ignore it. As there are probably enough cases where this isn't happening
> (i.e. enough sites that do rely on CSS content for important content),
> assistive technology had to adapt.

There is an alternative to using
li:before{content:'txt'}
and that is to use the ::marker pseudo element:
li::marker{content:'txt'}

The only parser I know with support for ::marker, is Prince XML. But at
any rate, I suppose that when support is there, the UA and screenreader
would know that the marker should not be read.

Another way to solve this problem would be to use media queries and
then to not send the 'content CSS' to the screenreaders. But so far,
screenreaders have not implemented media queries, so we are out of
luck.

Until further, I guess Bryan could use
li{list-style-image:url(plus-image-url)}
That should solve the issue. If scaling of the image is an issue, then
I presume that it starting to become possible to use svg images, which
should scale. Huh, it would even be possible to use the content:;
property, only filling it with no-break-space and then to place a
background image behind it.
--
Leif H Silli

From: Patrick H. Lauke
Date: Sun, Jan 08 2012 5:39AM
Subject: Re: Interesting effect with CSS
← Previous message | Next message →

On 08/01/2012 11:43, Leif Halvard Silli wrote:
> There is an alternative to using
> li:before{content:'txt'}
> and that is to use the ::marker pseudo element:
> li::marker{content:'txt'}
>
> The only parser I know with support for ::marker, is Prince XML. But at
> any rate, I suppose that when support is there, the UA and screenreader
> would know that the marker should not be read.

...but in the meantime that content will be available to nobody? (unless
they're using Prince XML)

> Another way to solve this problem would be to use media queries and
> then to not send the 'content CSS' to the screenreaders. But so far,
> screenreaders have not implemented media queries, so we are out of
> luck.

I don't think there's any media type of media query property that can be
used specifically to target "screenreaders", and I doubt there will be
in the near future.

Heck, there's no way to specifically target "handheld" or "tv" - even
though media *types* for those actually do exist - they are simply
ignored by all user agents on those particular devices because,
historically, they have been used to send "lower quality / lowest common
denominator" type styles to old devices (exceptions here: Opera Mini
reacts to "handheld", but only if users have enabled the "single column
view" option, and the only major device that obeys "tv" is, to my
knowledge, the first generation Nintendo Wii internet channel, i.e.
Opera 9. (full disclosure: I work for Opera, but I'm not saying these
for promotional purposes, but because I believe they're technically
accurate).

P
--
Patrick H. Lauke

From: Jared Smith
Date: Sun, Jan 08 2012 5:51AM
Subject: Re: Interesting effect with CSS
← Previous message | Next message →

On Sun, Jan 8, 2012 at 4:43 AM, Leif Halvard Silli wrote:

> Another way to solve this problem would be to use media queries and
> then to not send the 'content CSS' to the screenreaders. But so far,
> screenreaders have not implemented media queries, so we are out of
> luck.

As Patrick noted, there's not really a media type for screen readers.
There was a proposal for a "reader" type at one point. There currently
is a "speech" media type (formerly known as "aural"), which is for
"speech synthesizers", which I guess means screen readers. There's
also accessibility-related "braille", "embossed", and "tty".

This always brings up a bit of a heated debate - whether it's
acceptable for user agents to identify assistive technology and/or
disability. The community is generally very opposed to this
self-identification. While this seems like a good idea, I doubt that
assistive technologies are likely to start identifying themselves in a
way that would render these media types of any use.

Jared

From: Leif Halvard Silli
Date: Sun, Jan 08 2012 6:06AM
Subject: Re: Interesting effect with CSS
← Previous message | Next message →

Patrick H. Lauke, Sun, 08 Jan 2012 12:41:15 +0000:
> On 08/01/2012 11:43, Leif Halvard Silli wrote:
>> There is an alternative to using
>> li:before{content:'txt'}
>> and that is to use the ::marker pseudo element:
>> li::marker{content:'txt'}
>>
>> The only parser I know with support for ::marker, is Prince XML. But at
>> any rate, I suppose that when support is there, the UA and screenreader
>> would know that the marker should not be read.
>
> ...but in the meantime that content will be available to nobody? (unless
> they're using Prince XML)

True. But I was justing trying to point out that the problem is not
really that the CSS content:; property causes things to be read by
screen readers. Rather the problem is that the content attribute, in
this case, was applied to the wrong feature.

>> Another way to solve this problem would be to use media queries and
>> then to not send the 'content CSS' to the screenreaders. But so far,
>> screenreaders have not implemented media queries, so we are out of
>> luck.
>
> I don't think there's any media type of media query property that can be
> used specifically to target "screenreaders", and I doubt there will be
> in the near future.

Agree. But the trend towards rendering generated content in screen
readers, makes it more reasonable that screen readers *would* support
such a thing. Quite a few things could have been solved that way. In
fact, the trick to use generated CSS to hide things from screen
readers, is just a variant of the normal screen reader hacks: Do
something 'weird' that screen readers either don't understand or
something which only they would render.

> Heck, there's no way to specifically target "handheld" or "tv" - even
> though media *types* for those actually do exist - they are simply
> ignored by all user agents on those particular devices because,
> historically, they have been used to send "lower quality / lowest common
> denominator" type styles to old devices (exceptions here: Opera Mini
> reacts to "handheld", but only if users have enabled the "single column
> view" option,

I almost always do use it in that mode ...

> and the only major device that obeys "tv" is, to my
> knowledge, the first generation Nintendo Wii internet channel, i.e.
> Opera 9. (full disclosure: I work for Opera, but I'm not saying these
> for promotional purposes, but because I believe they're technically
> accurate).

It is at least possible to limit certain styles to @media screen, in
order to enhance content for the 'screen' media - whoever that consider
themselves as such. Also @media print is known to work quite OK. That
there are some failures, is not a reason for screen readers to not
implement @media screenreader [yes, there is a proposal for such a
media].
--
Leif H Silli

From: Leif Halvard Silli
Date: Sun, Jan 08 2012 6:18AM
Subject: Re: Interesting effect with CSS
← Previous message | Next message →

Jared Smith, Sun, 8 Jan 2012 05:49:18 -0700:
> On Sun, Jan 8, 2012 at 4:43 AM, Leif Halvard Silli wrote:
>
>> Another way to solve this problem would be to use media queries and
>> then to not send the 'content CSS' to the screenreaders. But so far,
>> screenreaders have not implemented media queries, so we are out of
>> luck.
>
> As Patrick noted, there's not really a media type for screen readers.
> There was a proposal for a "reader" type at one point. There currently
> is a "speech" media type (formerly known as "aural"), which is for
> "speech synthesizers", which I guess means screen readers. There's
> also accessibility-related "braille", "embossed", and "tty".

I *imagined* that the 'reader' type was not meant to be identical with
'speech'. But perhaps I am quite wrong there. From what you say below,
it could seem that you are right, however.

> This always brings up a bit of a heated debate - whether it's
> acceptable for user agents to identify assistive technology and/or
> disability.

The 'speech' label does not need to be a disability label.

> The community is generally very opposed to this self-identification.

Interesting. This is the first time I have been made aware of that
angle of looking at it.

> While this seems like a good idea, I doubt that
> assistive technologies are likely to start identifying themselves in a
> way that would render these media types of any use.

Unfortunately, you could be right. Anyway, CSS generated content from
::before and ::after, has been incorporated into ARIA 1.0: [1]

]]]
Text nodes are often visited because they are children of an element
that uses rule 2C to collect text from its children. However, because
it is possible to specify or alter textual content using CSS rules, it
is necessary for user agents to combine such content, as appropriate,
with the text referenced by the text nodes to produce a complete text
alternative. An example is the use of CSS :before and :after
pseudo-elements, where the user agent combines the textual content
specified in the style sheet with that given in the DOM.
- When an image replaces text, then the UA should use the original
text, since that text is presumably the equivalent.
- When text replaces an image, then the UA should provide that text.
- When new text replaces old, then the UA should include the new
text, since that is what is rendered on screen.
[[[

[1] http://www.w3.org/TR/wai-aria/complete#textalternativecomputation
--
leif halvard silli

From: Patrick H. Lauke
Date: Sun, Jan 08 2012 6:36AM
Subject: Re: Interesting effect with CSS
← Previous message | Next message →

On 08/01/2012 13:06, Leif Halvard Silli wrote:
> True. But I was justing trying to point out that the problem is not
> really that the CSS content:; property causes things to be read by
> screen readers. Rather the problem is that the content attribute, in
> this case, was applied to the wrong feature.

Ah, gotcha.

>> Heck, there's no way to specifically target "handheld" or "tv" - even
>> though media *types* for those actually do exist - they are simply
>> ignored by all user agents on those particular devices because,
>> historically, they have been used to send "lower quality / lowest common
>> denominator" type styles to old devices (exceptions here: Opera Mini
>> reacts to "handheld", but only if users have enabled the "single column
>> view" option,
>
> I almost always do use it in that mode ...

So *you're* that one user we get on our stats? ;)

Nah, makes sense on devices with small screens, no doubt.

> It is at least possible to limit certain styles to @media screen, in
> order to enhance content for the 'screen' media - whoever that consider
> themselves as such. Also @media print is known to work quite OK. That
> there are some failures, is not a reason for screen readers to not
> implement @media screenreader [yes, there is a proposal for such a
> media].

I think "screen" and "print" are the types that are most
prevalent/used/supported. The other ones withered away. Even with the
current big push for mobile, "handheld" is being ignored (because of its
historical use)...and as mobile is one of THE biggest drivers at the
moment, I take that as evidence that the model of media types is being
abandoned (for that particular "devices identifying themselves of a
particular type from the restricted pool of available choices" way of
thinking). If "handheld" isn't being pushed despite the big push for
mobile, then I have little hope that "screenreader" or similar will make
the cut.

P
--
Patrick H. Lauke

From: Leif Halvard Silli
Date: Sun, Jan 08 2012 7:12AM
Subject: Re: Interesting effect with CSS
← Previous message | Next message →

Patrick H. Lauke, Sun, 08 Jan 2012 13:36:27 +0000:
> On 08/01/2012 13:06, Leif Halvard Silli wrote:

>> I almost always do use it in that mode ...
>
> So *you're* that one user we get on our stats? ;)

Bingo.

> Nah, makes sense on devices with small screens, no doubt.

How do you know ... ;-D

>> It is at least possible to limit certain styles to @media screen, in
>> order to enhance content for the 'screen' media - whoever that consider
>> themselves as such. Also @media print is known to work quite OK. That
>> there are some failures, is not a reason for screen readers to not
>> implement @media screenreader [yes, there is a proposal for such a
>> media].
>
> I think "screen" and "print" are the types that are most
> prevalent/used/supported. The other ones withered away. Even with the
> current big push for mobile, "handheld" is being ignored (because of its
> historical use)...and as mobile is one of THE biggest drivers at the
> moment, I take that as evidence that the model of media types is being
> abandoned (for that particular "devices identifying themselves of a
> particular type from the restricted pool of available choices" way of
> thinking). If "handheld" isn't being pushed despite the big push for
> mobile, then I have little hope that "screenreader" or similar will make
> the cut.

I disagree slightly with your analysis: The Opera Mini behavior shows
that users could voluntarily opt to have their 'reader' identify as
something that gives them a better experience. Heck, who hasn't, at
timed, used a 'print' version of a page, simply to avoid all the ads an
all that jazz? Right now I also remember about an AT developer I spoke
with, and which made a specialized browser for a pop news site, which
always loaded the the pages that were of lover quality. And even for
mobiles, there is a tendency to use specialized mobile versions of the
pages, rather than using media queries - doesn't sound as if the very
idea of more basic quality - or how you would put it - for certain
devises, is exactly dead.
--
Leif Halvard Silli

From: Patrick H. Lauke
Date: Sun, Jan 08 2012 8:30AM
Subject: Re: Interesting effect with CSS
← Previous message | Next message →

On 08/01/2012 14:14, Leif Halvard Silli wrote:
> Patrick H. Lauke, Sun, 08 Jan 2012 13:36:27 +0000:

> I disagree slightly with your analysis: The Opera Mini behavior shows
> that users could voluntarily opt to have their 'reader' identify as
> something that gives them a better experience.

Sure, but by default browsers will identify as whatever gets them the
best layout (which is why mobile browsers consistently say they're
"screen" devices, to avoid getting fed low-end layouts while they're in
fact capable of high-end rendering).

Apart from that one option in Opera Mini, I don't think any other mobile
browser obeys "handheld" nor offers an option to do so. That's why I
doubt desktop browsers etc will start to offer this option.

Another hindrance, in my view, has been that CSS media types are
mutually exclusive. A device can't say "I'm both a screen device AND a
handheld"...it's either/or. And as the majority of styles out in the
wild web target "screen" (when really, in most cases, they could just
target "all"), devices opt to say they're "screen".

If CSS spec was changed to say "a device can read 'screen' AND, if there
are specific 'handheld' styles, also use those" then we'd have quite a
powerful new mechanism for cross-device layouts etc. Alas, the spec
doesn't allow it. Btw this is a similar discussion I've been having
recently about the type "tv"...and the exact same reason why Opera on
TVs (Sony Bravias, Philips, etc) obeys "screen" rather than "tv"...

Sorry, long rambling to say: I wouldn't hold my breath, even if a
portion of users would love to have the ability...

> doesn't sound as if the very
> idea of more basic quality - or how you would put it - for certain
> devises, is exactly dead.

But specifically for "handheld", those styles generally assumed "a
device that barely supports CSS 1, and even there with huge exceptions".
I'm all for optimised, simplified layouts (which is what we're seeing
with mobile-specific sites, or even with fancy new
responsive/mediaqueried sites)...but those styles for old handheld
devices (think around 1995s capabilities or thereabouts) do a lot more
harm than good...and sadly, there's enough legacy of that sort on the
web to avoid having it enabled again on modern devices - as the large
majority of customers would simply complain ("Opera is stupid, it
renders my pages with no styles..." et al)

P
--
Patrick H. Lauke

From: Ryan Hemphill
Date: Sun, Jan 08 2012 5:42PM
Subject: Re: Interesting effect with CSS
← Previous message | Next message →

I've run some tests on that. It's inconsistent at best and can also
interfere with the formatting in some cases because it is deleted (at least
it appears) AFTER added to JAWS' virtual buffer.

That's my 2 cents.

Ryan
On Jan 7, 2012 9:29 PM, "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
wrote:

> I came a cross this the other day.
>
> For a while I thought that using the CSS technique :after or :before would
> be useful for displaying content visually but hiding it from screen
> readers, such as adding a graphical arrow or plus/minus sign on a menu or
> similar like so:
>
> li.treeitem:after {
> content: '+';
> }
>
> Which is invisible in IE using JAWS and NVDA. However this actually is
> visible in both JAWS and NVDA using Firefox.
>
> No idea if this is helpful or not, but I thought it was interesting.
>
> Bryan
>

From: Bryan Garaventa
Date: Mon, Jan 09 2012 10:03AM
Subject: Re: Interesting effect with CSS
← Previous message | Next message →

Thanks, when you say deleted, is it briefly showing up in the DOM? I've
wondered how CSS renders content without actually changing the DOM, do you
know how this is done?

----- Original Message -----
From: "Ryan Hemphill" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Sunday, January 08, 2012 4:43 PM
Subject: Re: [WebAIM] Interesting effect with CSS


> I've run some tests on that. It's inconsistent at best and can also
> interfere with the formatting in some cases because it is deleted (at
> least
> it appears) AFTER added to JAWS' virtual buffer.
>
> That's my 2 cents.
>
> Ryan
> On Jan 7, 2012 9:29 PM, "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> I came a cross this the other day.
>>
>> For a while I thought that using the CSS technique :after or :before
>> would
>> be useful for displaying content visually but hiding it from screen
>> readers, such as adding a graphical arrow or plus/minus sign on a menu or
>> similar like so:
>>
>> li.treeitem:after {
>> content: '+';
>> }
>>
>> Which is invisible in IE using JAWS and NVDA. However this actually is
>> visible in both JAWS and NVDA using Firefox.
>>
>> No idea if this is helpful or not, but I thought it was interesting.
>>
>> Bryan
>>

From: Ryan Hemphill
Date: Mon, Jan 09 2012 12:15PM
Subject: Re: Interesting effect with CSS
← Previous message | Next message →

No, what I mean is that the content is somehow being scraped by JAWS and
then dumped afterwards. It isn't necessarily the DOM at all and I suspect
it isn't. While I can't much without doubt, I am absolutely certain that
it is being somehow brought into the virtual buffer BEFORE it is deleted.

Also, take into account that you are able to copy/paste the :before/:after
text by normal mouse highlighting means. I haven't tried doing this
through JAWS but I imagine there might be some fascinating results if
someone is interested in pursuing it.

My guess is that they are pulling all the CSS so they can keep it in mind
for future releases and deleting/ignoring everything that isn't currently
important. Other than that fact, I know as much as the rest of you.

Wouldn't it be interesting if JAWS had it's own 'virtual browser'? And if
that were the case, would be it using things like webkit? Hmmm. It would
certainly explain some of the bugs I have seen from time to time.

Food for thought.




On Mon, Jan 9, 2012 at 12:05 PM, Bryan Garaventa <
= EMAIL ADDRESS REMOVED = > wrote:

> Thanks, when you say deleted, is it briefly showing up in the DOM? I've
> wondered how CSS renders content without actually changing the DOM, do you
> know how this is done?
>
> ----- Original Message -----
> From: "Ryan Hemphill" < = EMAIL ADDRESS REMOVED = >
> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
> Sent: Sunday, January 08, 2012 4:43 PM
> Subject: Re: [WebAIM] Interesting effect with CSS
>
>
> > I've run some tests on that. It's inconsistent at best and can also
> > interfere with the formatting in some cases because it is deleted (at
> > least
> > it appears) AFTER added to JAWS' virtual buffer.
> >
> > That's my 2 cents.
> >
> > Ryan
> > On Jan 7, 2012 9:29 PM, "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
> > wrote:
> >
> >> I came a cross this the other day.
> >>
> >> For a while I thought that using the CSS technique :after or :before
> >> would
> >> be useful for displaying content visually but hiding it from screen
> >> readers, such as adding a graphical arrow or plus/minus sign on a menu
> or
> >> similar like so:
> >>
> >> li.treeitem:after {
> >> content: '+';
> >> }
> >>
> >> Which is invisible in IE using JAWS and NVDA. However this actually is
> >> visible in both JAWS and NVDA using Firefox.
> >>
> >> No idea if this is helpful or not, but I thought it was interesting.
> >>
> >> Bryan
> >>

From: Vincent Young
Date: Tue, Jan 17 2012 5:33PM
Subject: Re: Interesting effect with CSS
← Previous message | Next message →

A Site Point article just came out which makes use of the CSS content
attribute:

http://www.sitepoint.com/webfont-icons/

The example creates an "icon font" where images are mapped to characters so
that instead of using background images, you use a single font to generate
all your site's icon images.

The accessibility problem is one we discussed in this thread, the content
attribute is used to add the characters which NVDA has problems with.

I've put together an example which works visually in all browsers including
IE6 and IE7:

http://www.webhipster.com/testing/accessibility/webfonts/ie.html

You will hear b then rss when you focus the link which is obviously not
ideal. We want is just rss.


I've put together another example using a font which uses unicode
characters to map to images (instead of a-z) which seems to be fine in
NVDA. However, this does not work in IE6 and IE7 which is why the previous
example does not use unicode characters.

http://www.webhipster.com/testing/accessibility/webfonts/non-ie.html


So, this example seems to be OK, but I'm wondering what the best solution
is when you need to support IE6 and IE7?

Is there a standard we should be advocating within the development
community for this type of technique? I assume this will get more popular
and we should have a consensus.



On Mon, Jan 9, 2012 at 2:14 PM, Ryan Hemphill
< = EMAIL ADDRESS REMOVED = >wrote:

> No, what I mean is that the content is somehow being scraped by JAWS and
> then dumped afterwards. It isn't necessarily the DOM at all and I suspect
> it isn't. While I can't much without doubt, I am absolutely certain that
> it is being somehow brought into the virtual buffer BEFORE it is deleted.
>
> Also, take into account that you are able to copy/paste the :before/:after
> text by normal mouse highlighting means. I haven't tried doing this
> through JAWS but I imagine there might be some fascinating results if
> someone is interested in pursuing it.
>
> My guess is that they are pulling all the CSS so they can keep it in mind
> for future releases and deleting/ignoring everything that isn't currently
> important. Other than that fact, I know as much as the rest of you.
>
> Wouldn't it be interesting if JAWS had it's own 'virtual browser'? And if
> that were the case, would be it using things like webkit? Hmmm. It would
> certainly explain some of the bugs I have seen from time to time.
>
> Food for thought.
>
>
>
>
> On Mon, Jan 9, 2012 at 12:05 PM, Bryan Garaventa <
> = EMAIL ADDRESS REMOVED = > wrote:
>
> > Thanks, when you say deleted, is it briefly showing up in the DOM? I've
> > wondered how CSS renders content without actually changing the DOM, do
> you
> > know how this is done?
> >
> > ----- Original Message -----
> > From: "Ryan Hemphill" < = EMAIL ADDRESS REMOVED = >
> > To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
> > Sent: Sunday, January 08, 2012 4:43 PM
> > Subject: Re: [WebAIM] Interesting effect with CSS
> >
> >
> > > I've run some tests on that. It's inconsistent at best and can also
> > > interfere with the formatting in some cases because it is deleted (at
> > > least
> > > it appears) AFTER added to JAWS' virtual buffer.
> > >
> > > That's my 2 cents.
> > >
> > > Ryan
> > > On Jan 7, 2012 9:29 PM, "Bryan Garaventa" <
> = EMAIL ADDRESS REMOVED = >
> > > wrote:
> > >
> > >> I came a cross this the other day.
> > >>
> > >> For a while I thought that using the CSS technique :after or :before
> > >> would
> > >> be useful for displaying content visually but hiding it from screen
> > >> readers, such as adding a graphical arrow or plus/minus sign on a menu
> > or
> > >> similar like so:
> > >>
> > >> li.treeitem:after {
> > >> content: '+';
> > >> }
> > >>
> > >> Which is invisible in IE using JAWS and NVDA. However this actually is
> > >> visible in both JAWS and NVDA using Firefox.
> > >>
> > >> No idea if this is helpful or not, but I thought it was interesting.
> > >>
> > >> Bryan
> > >>

From: Vincent Young
Date: Wed, Jan 18 2012 4:03PM
Subject: Re: Interesting effect with CSS
← Previous message | Next message →

After doing a bit more research and testing, font images should be
avoided. Even when they are mapped directly to their unicode image
equivalent they can cause problems as some unicode values are spoken by
assistive technology, even when using the CSS content attribute. This if
often undesirable. Jason Santa Maria makes sense of the semantic and
accessibility issues in this article:
http://jontangerine.com/log/2010/08/web-fonts-dingbats-icons-and-unicode

Other scalable image techniques such as SVG (VML for IE) should be explored.


On Tue, Jan 17, 2012 at 4:34 PM, Vincent Young < = EMAIL ADDRESS REMOVED = >wrote:

> A Site Point article just came out which makes use of the CSS content
> attribute:
>
> http://www.sitepoint.com/webfont-icons/
>
> The example creates an "icon font" where images are mapped to characters
> so that instead of using background images, you use a single font to
> generate all your site's icon images.
>
> The accessibility problem is one we discussed in this thread, the content
> attribute is used to add the characters which NVDA has problems with.
>
> I've put together an example which works visually in all browsers
> including IE6 and IE7:
>
> http://www.webhipster.com/testing/accessibility/webfonts/ie.html
>
> You will hear b then rss when you focus the link which is obviously not
> ideal. We want is just rss.
>
>
> I've put together another example using a font which uses unicode
> characters to map to images (instead of a-z) which seems to be fine in
> NVDA. However, this does not work in IE6 and IE7 which is why the previous
> example does not use unicode characters.
>
> http://www.webhipster.com/testing/accessibility/webfonts/non-ie.html
>
>
> So, this example seems to be OK, but I'm wondering what the best solution
> is when you need to support IE6 and IE7?
>
> Is there a standard we should be advocating within the development
> community for this type of technique? I assume this will get more popular
> and we should have a consensus.
>
>
>
> On Mon, Jan 9, 2012 at 2:14 PM, Ryan Hemphill <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> No, what I mean is that the content is somehow being scraped by JAWS and
>> then dumped afterwards. It isn't necessarily the DOM at all and I suspect
>> it isn't. While I can't much without doubt, I am absolutely certain that
>> it is being somehow brought into the virtual buffer BEFORE it is deleted.
>>
>> Also, take into account that you are able to copy/paste the :before/:after
>> text by normal mouse highlighting means. I haven't tried doing this
>> through JAWS but I imagine there might be some fascinating results if
>> someone is interested in pursuing it.
>>
>> My guess is that they are pulling all the CSS so they can keep it in mind
>> for future releases and deleting/ignoring everything that isn't currently
>> important. Other than that fact, I know as much as the rest of you.
>>
>> Wouldn't it be interesting if JAWS had it's own 'virtual browser'? And if
>> that were the case, would be it using things like webkit? Hmmm. It would
>> certainly explain some of the bugs I have seen from time to time.
>>
>> Food for thought.
>>
>>
>>
>>
>> On Mon, Jan 9, 2012 at 12:05 PM, Bryan Garaventa <
>> = EMAIL ADDRESS REMOVED = > wrote:
>>
>> > Thanks, when you say deleted, is it briefly showing up in the DOM? I've
>> > wondered how CSS renders content without actually changing the DOM, do
>> you
>> > know how this is done?
>> >
>> > ----- Original Message -----
>> > From: "Ryan Hemphill" < = EMAIL ADDRESS REMOVED = >
>> > To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
>> > Sent: Sunday, January 08, 2012 4:43 PM
>> > Subject: Re: [WebAIM] Interesting effect with CSS
>> >
>> >
>> > > I've run some tests on that. It's inconsistent at best and can also
>> > > interfere with the formatting in some cases because it is deleted (at
>> > > least
>> > > it appears) AFTER added to JAWS' virtual buffer.
>> > >
>> > > That's my 2 cents.
>> > >
>> > > Ryan
>> > > On Jan 7, 2012 9:29 PM, "Bryan Garaventa" <
>> = EMAIL ADDRESS REMOVED = >
>> > > wrote:
>> > >
>> > >> I came a cross this the other day.
>> > >>
>> > >> For a while I thought that using the CSS technique :after or :before
>> > >> would
>> > >> be useful for displaying content visually but hiding it from screen
>> > >> readers, such as adding a graphical arrow or plus/minus sign on a
>> menu
>> > or
>> > >> similar like so:
>> > >>
>> > >> li.treeitem:after {
>> > >> content: '+';
>> > >> }
>> > >>
>> > >> Which is invisible in IE using JAWS and NVDA. However this actually
>> is
>> > >> visible in both JAWS and NVDA using Firefox.
>> > >>
>> > >> No idea if this is helpful or not, but I thought it was interesting.
>> > >>
>> > >> Bryan
>> > >>

From: Bryan Garaventa
Date: Thu, Jan 19 2012 12:42AM
Subject: Re: Interesting effect with CSS
← Previous message | No next message

Sounds great, thanks :) It helps a lot to have the behavior verified.

----- Original Message -----
From: "Vincent Young" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Wednesday, January 18, 2012 3:05 PM
Subject: Re: [WebAIM] Interesting effect with CSS


> After doing a bit more research and testing, font images should be
> avoided. Even when they are mapped directly to their unicode image
> equivalent they can cause problems as some unicode values are spoken by
> assistive technology, even when using the CSS content attribute. This if
> often undesirable. Jason Santa Maria makes sense of the semantic and
> accessibility issues in this article:
> http://jontangerine.com/log/2010/08/web-fonts-dingbats-icons-and-unicode
>
> Other scalable image techniques such as SVG (VML for IE) should be
> explored.
>
>
> On Tue, Jan 17, 2012 at 4:34 PM, Vincent Young
> < = EMAIL ADDRESS REMOVED = >wrote:
>
>> A Site Point article just came out which makes use of the CSS content
>> attribute:
>>
>> http://www.sitepoint.com/webfont-icons/
>>
>> The example creates an "icon font" where images are mapped to characters
>> so that instead of using background images, you use a single font to
>> generate all your site's icon images.
>>
>> The accessibility problem is one we discussed in this thread, the content
>> attribute is used to add the characters which NVDA has problems with.
>>
>> I've put together an example which works visually in all browsers
>> including IE6 and IE7:
>>
>> http://www.webhipster.com/testing/accessibility/webfonts/ie.html
>>
>> You will hear b then rss when you focus the link which is obviously not
>> ideal. We want is just rss.
>>
>>
>> I've put together another example using a font which uses unicode
>> characters to map to images (instead of a-z) which seems to be fine in
>> NVDA. However, this does not work in IE6 and IE7 which is why the
>> previous
>> example does not use unicode characters.
>>
>> http://www.webhipster.com/testing/accessibility/webfonts/non-ie.html
>>
>>
>> So, this example seems to be OK, but I'm wondering what the best solution
>> is when you need to support IE6 and IE7?
>>
>> Is there a standard we should be advocating within the development
>> community for this type of technique? I assume this will get more
>> popular
>> and we should have a consensus.
>>
>>
>>
>> On Mon, Jan 9, 2012 at 2:14 PM, Ryan Hemphill <
>> = EMAIL ADDRESS REMOVED = > wrote:
>>
>>> No, what I mean is that the content is somehow being scraped by JAWS and
>>> then dumped afterwards. It isn't necessarily the DOM at all and I
>>> suspect
>>> it isn't. While I can't much without doubt, I am absolutely certain
>>> that
>>> it is being somehow brought into the virtual buffer BEFORE it is
>>> deleted.
>>>
>>> Also, take into account that you are able to copy/paste the
>>> :before/:after
>>> text by normal mouse highlighting means. I haven't tried doing this
>>> through JAWS but I imagine there might be some fascinating results if
>>> someone is interested in pursuing it.
>>>
>>> My guess is that they are pulling all the CSS so they can keep it in
>>> mind
>>> for future releases and deleting/ignoring everything that isn't
>>> currently
>>> important. Other than that fact, I know as much as the rest of you.
>>>
>>> Wouldn't it be interesting if JAWS had it's own 'virtual browser'? And
>>> if
>>> that were the case, would be it using things like webkit? Hmmm. It
>>> would
>>> certainly explain some of the bugs I have seen from time to time.
>>>
>>> Food for thought.
>>>
>>>
>>>
>>>
>>> On Mon, Jan 9, 2012 at 12:05 PM, Bryan Garaventa <
>>> = EMAIL ADDRESS REMOVED = > wrote:
>>>
>>> > Thanks, when you say deleted, is it briefly showing up in the DOM?
>>> > I've
>>> > wondered how CSS renders content without actually changing the DOM, do
>>> you
>>> > know how this is done?
>>> >
>>> > ----- Original Message -----
>>> > From: "Ryan Hemphill" < = EMAIL ADDRESS REMOVED = >
>>> > To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
>>> > Sent: Sunday, January 08, 2012 4:43 PM
>>> > Subject: Re: [WebAIM] Interesting effect with CSS
>>> >
>>> >
>>> > > I've run some tests on that. It's inconsistent at best and can also
>>> > > interfere with the formatting in some cases because it is deleted
>>> > > (at
>>> > > least
>>> > > it appears) AFTER added to JAWS' virtual buffer.
>>> > >
>>> > > That's my 2 cents.
>>> > >
>>> > > Ryan
>>> > > On Jan 7, 2012 9:29 PM, "Bryan Garaventa" <
>>> = EMAIL ADDRESS REMOVED = >
>>> > > wrote:
>>> > >
>>> > >> I came a cross this the other day.
>>> > >>
>>> > >> For a while I thought that using the CSS technique :after or
>>> > >> :before
>>> > >> would
>>> > >> be useful for displaying content visually but hiding it from screen
>>> > >> readers, such as adding a graphical arrow or plus/minus sign on a
>>> menu
>>> > or
>>> > >> similar like so:
>>> > >>
>>> > >> li.treeitem:after {
>>> > >> content: '+';
>>> > >> }
>>> > >>
>>> > >> Which is invisible in IE using JAWS and NVDA. However this actually
>>> is
>>> > >> visible in both JAWS and NVDA using Firefox.
>>> > >>
>>> > >> No idea if this is helpful or not, but I thought it was
>>> > >> interesting.
>>> > >>
>>> > >> Bryan
>>> > >>