E-mail List Archives
Thread: hide decorative characters from screen readers
Number of posts in this thread: 17 (In chronological order)
From: Yves Serrano
Date: Fri, Aug 12 2011 2:36AM
Subject: hide decorative characters from screen readers
No previous message | Next message →
Hi
Often you have a character as navigation separator in horizontal navigation list.
I use for example "-" or "|". The screen readers reads this characters even if I build them with pseudo css content (JAWS).
I could use images as <li> background, but then I lose the ability of scaling via css, by changing the font size.
It also matches the text better if I don't use an image.
We can hide decorative images with the empty alt attribute from the screen reader is there a solution for
decorative characters?
Don't found anything. Am I the only one who does it find unpleasing when the screen reader reads them?
regards yves
From: Léonie Watson
Date: Fri, Aug 12 2011 6:36AM
Subject: Re: hide decorative characters from screen readers
← Previous message | Next message →
Yves Serrano wrote:
"We can hide decorative images with the empty alt attribute from the screen
reader is there a solution for decorative characters?"
The following article looks at the different techniques you can use
for hiding content from sight (as well as from everybody). Hope it helps.
http://www.nomensa.com/blog/2011/hiding-content/
Léonie.
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Yves Serrano
Sent: 12 August 2011 09:38
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] hide decorative characters from screen readers
Hi
Often you have a character as navigation separator in horizontal navigation
list.
I use for example "-" or "|". The screen readers reads this characters even
if I build them with pseudo css content (JAWS).
I could use images as <li> background, but then I lose the ability of
scaling via css, by changing the font size.
It also matches the text better if I don't use an image.
We can hide decorative images with the empty alt attribute from the screen
reader is there a solution for decorative characters?
Don't found anything. Am I the only one who does it find unpleasing when the
screen reader reads them?
regards yves
From: YOUNGV5@nationwide.com
Date: Fri, Aug 12 2011 6:51AM
Subject: Re: hide decorative characters from screen readers
← Previous message | Next message →
Léonie, I believe Yves was inquiring about situations where the content is
visible, but hidden from screen reader users. The solutions at
http://www.nomensa.com/blog/2011/hiding-content/ either hides content from
both users or just hides content from visual users. I believe the
solution is to use role="presentation"
Example:
<span role="presentation">|</span>
Of course, this is a new technique. If you are looking for more of a
current universal solution possibly do the following:
Use an in-line image that is a bit larger than what you need and has empty
alt (alt=""). Then, incorporate some progressive techniques that allow
the image to scale.
Hope this points you in the right direction.
Cheers.
Vincent Young
User Experience, Web Accessibility Specialist
Nationwide Corporate Marketing
Nationwide®
o | 614·677·5094
c | 614·607·3400
e | = EMAIL ADDRESS REMOVED =
From:
Léonie Watson < = EMAIL ADDRESS REMOVED = >
To:
"'WebAIM Discussion List'" < = EMAIL ADDRESS REMOVED = >
Date:
08/12/2011 08:38 AM
Subject:
Re: [WebAIM] hide decorative characters from screen readers
Sent by:
= EMAIL ADDRESS REMOVED =
Yves Serrano wrote:
"We can hide decorative images with the empty alt attribute from the
screen
reader is there a solution for decorative characters?"
The following article looks at the different techniques
you can use
for hiding content from sight (as well as from everybody). Hope it helps.
http://www.nomensa.com/blog/2011/hiding-content/
Léonie.
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Yves Serrano
Sent: 12 August 2011 09:38
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] hide decorative characters from screen readers
Hi
Often you have a character as navigation separator in horizontal
navigation
list.
I use for example "-" or "|". The screen readers reads this characters
even
if I build them with pseudo css content (JAWS).
I could use images as <li> background, but then I lose the ability of
scaling via css, by changing the font size.
It also matches the text better if I don't use an image.
We can hide decorative images with the empty alt attribute from the screen
reader is there a solution for decorative characters?
Don't found anything. Am I the only one who does it find unpleasing when
the
screen reader reads them?
regards yves
From: Birkir R. Gunnarsson
Date: Fri, Aug 12 2011 8:00AM
Subject: Re: hide decorative characters from screen readers
← Previous message | Next message →
I, as a screen reader user, actually don't mind seeind ghe |
separation character in lists. Sure, it adds an extra line of
scrolling between list items, but it also makes the separation
extremely clear.
It's never bothered me, and I think I might be able to get rid of it
by changing the punctuation pronounciation options in Jaws (though may
be this does not apply to browsing situation, I have to check that).
But, just to add an opinion, I find a lot of things a lot more
frustrating than the occasional separation character.
Cheers
-B
On 8/12/11, = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > wrote:
> Léonie, I believe Yves was inquiring about situations where the content is
> visible, but hidden from screen reader users. The solutions at
> http://www.nomensa.com/blog/2011/hiding-content/ either hides content from
> both users or just hides content from visual users. I believe the
> solution is to use role="presentation"
>
> Example:
>
> <span role="presentation">|</span>
>
> Of course, this is a new technique. If you are looking for more of a
> current universal solution possibly do the following:
>
> Use an in-line image that is a bit larger than what you need and has empty
> alt (alt=""). Then, incorporate some progressive techniques that allow
> the image to scale.
>
> Hope this points you in the right direction.
>
> Cheers.
>
>
>
>
>
> Vincent Young
> User Experience, Web Accessibility Specialist
> Nationwide Corporate Marketing
> Nationwide®
> o | 614·677·5094
> c | 614·607·3400
> e | = EMAIL ADDRESS REMOVED =
>
>
>
>
> From:
> Léonie Watson < = EMAIL ADDRESS REMOVED = >
> To:
> "'WebAIM Discussion List'" < = EMAIL ADDRESS REMOVED = >
> Date:
> 08/12/2011 08:38 AM
> Subject:
> Re: [WebAIM] hide decorative characters from screen readers
> Sent by:
> = EMAIL ADDRESS REMOVED =
>
>
>
> Yves Serrano wrote:
> "We can hide decorative images with the empty alt attribute from the
> screen
> reader is there a solution for decorative characters?"
>
> The following article looks at the different techniques
> you can use
> for hiding content from sight (as well as from everybody). Hope it helps.
> http://www.nomensa.com/blog/2011/hiding-content/
>
>
> Léonie.
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Yves Serrano
> Sent: 12 August 2011 09:38
> To: = EMAIL ADDRESS REMOVED =
> Subject: [WebAIM] hide decorative characters from screen readers
>
> Hi
>
> Often you have a character as navigation separator in horizontal
> navigation
> list.
> I use for example "-" or "|". The screen readers reads this characters
> even
> if I build them with pseudo css content (JAWS).
> I could use images as <li> background, but then I lose the ability of
> scaling via css, by changing the font size.
> It also matches the text better if I don't use an image.
>
> We can hide decorative images with the empty alt attribute from the screen
> reader is there a solution for decorative characters?
>
> Don't found anything. Am I the only one who does it find unpleasing when
> the
> screen reader reads them?
>
> regards yves
>
From: Lucy Greco
Date: Fri, Aug 12 2011 9:33AM
Subject: Re: hide decorative characters from screen readers
← Previous message | Next message →
This again is user choice. I don't mind the spaser but it does not get spoken to much in to many places but I hate hearing vertical bar vertical bar smile. Again user preferences are something you cannot predict . smile
Lucy Greco
Assistive Technology Specialist
Disabled Student's Program UC Berkeley
(510) 643-7591
http://attlc.berkeley.edu
http://webaccess.berkeley.edu
-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir R. Gunnarsson
Sent: Friday, August 12, 2011 7:01 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] hide decorative characters from screen readers
I, as a screen reader user, actually don't mind seeind ghe |
separation character in lists. Sure, it adds an extra line of
scrolling between list items, but it also makes the separation
extremely clear.
It's never bothered me, and I think I might be able to get rid of it
by changing the punctuation pronounciation options in Jaws (though may
be this does not apply to browsing situation, I have to check that).
But, just to add an opinion, I find a lot of things a lot more
frustrating than the occasional separation character.
Cheers
-B
On 8/12/11, = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > wrote:
> Léonie, I believe Yves was inquiring about situations where the content is
> visible, but hidden from screen reader users. The solutions at
> http://www.nomensa.com/blog/2011/hiding-content/ either hides content from
> both users or just hides content from visual users. I believe the
> solution is to use role="presentation"
>
> Example:
>
> <span role="presentation">|</span>
>
> Of course, this is a new technique. If you are looking for more of a
> current universal solution possibly do the following:
>
> Use an in-line image that is a bit larger than what you need and has empty
> alt (alt=""). Then, incorporate some progressive techniques that allow
> the image to scale.
>
> Hope this points you in the right direction.
>
> Cheers.
>
>
>
>
>
> Vincent Young
> User Experience, Web Accessibility Specialist
> Nationwide Corporate Marketing
> Nationwide®
> o | 614·677·5094
> c | 614·607·3400
> e | = EMAIL ADDRESS REMOVED =
>
>
>
>
> From:
> Léonie Watson < = EMAIL ADDRESS REMOVED = >
> To:
> "'WebAIM Discussion List'" < = EMAIL ADDRESS REMOVED = >
> Date:
> 08/12/2011 08:38 AM
> Subject:
> Re: [WebAIM] hide decorative characters from screen readers
> Sent by:
> = EMAIL ADDRESS REMOVED =
>
>
>
> Yves Serrano wrote:
> "We can hide decorative images with the empty alt attribute from the
> screen
> reader is there a solution for decorative characters?"
>
> The following article looks at the different techniques
> you can use
> for hiding content from sight (as well as from everybody). Hope it helps.
> http://www.nomensa.com/blog/2011/hiding-content/
>
>
> Léonie.
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Yves Serrano
> Sent: 12 August 2011 09:38
> To: = EMAIL ADDRESS REMOVED =
> Subject: [WebAIM] hide decorative characters from screen readers
>
> Hi
>
> Often you have a character as navigation separator in horizontal
> navigation
> list.
> I use for example "-" or "|". The screen readers reads this characters
> even
> if I build them with pseudo css content (JAWS).
> I could use images as <li> background, but then I lose the ability of
> scaling via css, by changing the font size.
> It also matches the text better if I don't use an image.
>
> We can hide decorative images with the empty alt attribute from the screen
> reader is there a solution for decorative characters?
>
> Don't found anything. Am I the only one who does it find unpleasing when
> the
> screen reader reads them?
>
> regards yves
>
From: John Foliot
Date: Fri, Aug 12 2011 1:00PM
Subject: Re: hide decorative characters from screen readers
← Previous message | Next message →
Yves Serrano wrote:
>
> Often you have a character as navigation separator in horizontal
> navigation list.
> I use for example "-" or "|". The screen readers reads this characters
> even if I build them with pseudo css content (JAWS).
Yes, I agree that screen readers (NVDA has the same behavior) shouldn't
real aloud :before or :after pseudo-selector characters. We have a
precedent here in that you cannot copy and paste those same characters
from the browser screen (they are treated like background images) and
screen readers should treat them the same way as well, IMHO.
Anyone disagree, and if so why (please)?
JF
From: Jukka K. Korpela
Date: Fri, Aug 12 2011 1:21PM
Subject: Re: hide decorative characters from screen readers
← Previous message | Next message →
12.8.2011 11:37, Yves Serrano wrote:
> Often you have a character as navigation separator in horizontal navigation list.
> I use for example "-" or "|".
Accessibility recommendations used to say that adjacent links should be
separatated by some non-whitespace characters so that they can be
recognized as separate links. This idea seems to have been ignored in
WCAG 2.0, but it looks rather natural to me.
Speech rendering might nowadays avoid the issue e.g. so that the word
"link" is pronounced before each link - though I don't know whether this
is really universal. But in visual rendering the issue remains. Even if
underlining of links has not been prevented by the author, it can be
difficult to notice where a link text ends and a new link text begings
> We can hide decorative images with the empty alt attribute from the screen reader is there a solution for
> decorative characters?
I don't think the separators are decorative. They have a function
comparable to punctuation marks in texts.
But if you think that they disturb speech rendering and are not needed
in non-visual rendering at all, you might consider using CSS to set a
right border for each link, with some padding before it. It would look
like a vertical bar, just taller (and you could easily set its width and
color), and it would not affect speech rendering.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
From: James Nurthen
Date: Fri, Aug 12 2011 1:42PM
Subject: Re: hide decorative characters from screen readers
← Previous message | Next message →
On Fri, Aug 12, 2011 at 11:57, John Foliot < = EMAIL ADDRESS REMOVED = > wrote:
> Yes, I agree that screen readers (NVDA has the same behavior) shouldn't
> real aloud :before or :after pseudo-selector characters. We have a
> precedent here in that you cannot copy and paste those same characters
> from the browser screen (they are treated like background images) and
> screen readers should treat them the same way as well, IMHO.
>
> Anyone disagree, and if so why (please)?
John, This is how it used to work - but WAI-ARIA introduces the following
into the accessible name calculation (
http://www.w3.org/TR/wai-aria/roles#textalternativecomputation )
3. 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.
>
>
>
>
From: Keith Parks
Date: Fri, Aug 12 2011 5:06PM
Subject: Re: hide decorative characters from screen readers
← Previous message | Next message →
On Aug 12, 2011, at 12:41 PM, James Nurthen wrote:
> John, This is how it used to work - but WAI-ARIA introduces the following
> into the accessible name calculation (
> http://www.w3.org/TR/wai-aria/roles#textalternativecomputation )
>
> 3. 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.
Huh?
Can you put that in *plain* English?
(Yes, I realize a lot of talk on this list is by nature fairly technical, but that one went right over my head.)
******************************
Keith Parks
Graphic Designer/Web Designer
Student Affairs Communications Services
San Diego State University
San Diego, CA 92182-7444
(619) 594-1046
mailto: = EMAIL ADDRESS REMOVED =
http://www.sa.sdsu.edu/communications
http://kparks.deviantart.com/gallery
----------------------------------------------------------
Yes We Can!*
*should not be interpreted to mean that we necessarily will
From: Chris Hoffman
Date: Fri, Aug 12 2011 5:30PM
Subject: Re: hide decorative characters from screen readers
← Previous message | Next message →
On Aug 12, 2011, at 7:05 PM, Keith Parks < = EMAIL ADDRESS REMOVED = > wrote:
>
>>>
> Huh?
>
> Can you put that in *plain* English?
>
> (Yes, I realize a lot of talk on this list is by nature fairly technical, but that one went right over my head.)
Mine, too, so I had to go to the link for context. This section of the ARIA spec is talking about how to determine alternative text for elements. Rule 2C says to calculate the alternative text by concatenating the text values of an element’s children, and this (confusingly written) note says that CSS-generated text content should be added into the mix. In other words, JAWS and NVDA are following the letter of the law, so to speak.
Chris
From: Keith Parks
Date: Fri, Aug 12 2011 5:39PM
Subject: Re: hide decorative characters from screen readers
← Previous message | Next message →
On Aug 12, 2011, at 4:30 PM, Chris Hoffman wrote:
> Mine, too, so I had to go to the link for context. This section of the ARIA spec is talking about how to determine alternative text for elements. Rule 2C says to calculate the alternative text by concatenating the text values of an element’s children, and this (confusingly written) note says that CSS-generated text content should be added into the mix.
Thanks.
So it would be a better practice to use CSS to add a visual separator (vertical line) rather than use CSS to add the vertical bar character?
Is that the take-away from this?
******************************
Keith Parks
Graphic Designer/Web Designer
Student Affairs Communications Services
San Diego State University
San Diego, CA 92182-7444
(619) 594-1046
mailto: = EMAIL ADDRESS REMOVED =
http://www.sa.sdsu.edu/communications
http://kparks.deviantart.com/gallery
----------------------------------------------------------
America - now "All You Can Eat" on Mondays and Thursdays!
From: John Foliot
Date: Fri, Aug 12 2011 6:30PM
Subject: Re: hide decorative characters from screen readers
← Previous message | Next message →
James Nurthen wrote:
>
> John, This is how it used to work - but WAI-ARIA introduces the
> following
> into the accessible name calculation (
> http://www.w3.org/TR/wai-aria/roles#textalternativecomputation )
>
> 3. 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.
Keith Parks
>
> > Mine, too, so I had to go to the link for context. This section of
> > the ARIA spec is talking about how to determine alternative text for
> > elements. Rule 2C says to calculate the alternative text by
> > concatenating the text values of an element's children, and this
> > (confusingly written) note says that CSS-generated text content should
> > be added into the mix.
>
> Thanks.
>
> So it would be a better practice to use CSS to add a visual separator
> (vertical line) rather than use CSS to add the vertical bar character?
>
> Is that the take-away from this?
Apparently it is, although I see this as doing as much harm as benefit,
and I don't totally agree with what WAI-ARIA is saying here.
If one were to try to highlight, copy and paste any text inserted with
those selectors that text is "left behind" at 'paste'.
My question is, why are screen readers reading content that is, from the
visual/interactive perspective more similar to background images (via
CSS)?
My thinking is that if text (and other characters) were not voiced that we
could do something like this:
=== code ==
<style>
label:before {
content: "* ";
color:red;
font-weight:bold;
}
</style>
</head>
<body>
<form action="do_something">
<label for="name">Name:</label> <input type="text" name="name" id="name"
required aria-required="true">
</form>
=== end code ==
This would result in a visual output of:
Name* |_________|
...but would read aloud: "Name (as opposed to name-star), input text,
required" (YMMV) which would result in a far superior user experience for
screen reader users IMHO.
What say y'all?
From: Chris Hoffman
Date: Fri, Aug 12 2011 6:54PM
Subject: Re: hide decorative characters from screen readers
← Previous message | Next message →
On Fri, Aug 12, 2011 at 7:36 PM, Keith Parks < = EMAIL ADDRESS REMOVED = > wrote:
> So it would be a better practice to use CSS to add a visual separator (vertical line) rather than use CSS to add the vertical bar character?
>
> Is that the take-away from this?
I think the takeaway is that we are reminded that there are two
conflicting schools of thought regarding web accessibility. The first
says that there are certain parts of a page that just don't need to be
perceivable because they are purely decorative. Icons in front of the
text in menu items, for example. The other school says that the only
person who can say what should and shouldn't be perceivable is the one
viewing the page, and that the tiny picture of an envelope in front of
the phrase "email us" is a part of the page content and should not be
hidden. The ARIA spec is siding with the first school. There are good
arguments on both sides, and you can undoubtedly hear them all from
the folks on this list.
From a design perspective, this makes Yves' original problem quite
difficult to resolve. He could use a border as a separator, but that's
not an ideal solution. A vertical bar that has been designed as part
of a typeface will likely look much better in the context of the rest
of the text, for example, and getting the border to resize
aesthetically when the rest of the text is resized would be difficult,
even if he specified the width in ems. If he uses an offset background
image, the resizing problem is even worse, since those won't resize at
all.
As Birkir pointed out, though (and I've seen this sentiment repeated
before), the extraneous separator characters might not be as big a
distraction as sighted designers think. As a user who is neither blind
nor visually-impaired, for example, I see the > characters that begin
every line of your quoted email above, and they give me information
about what those lines mean but don't distract me from reading them.
The fact that I can perceive the > characters with my eyes is
independent of the fact that I can ignore them when reading the quoted
lines, and there is little good reason to presume that someone who is
listening to rather than looking at the lines wouldn't do the same and
just as well.
Chris
From: Jason Kiss
Date: Fri, Aug 12 2011 7:15PM
Subject: Re: hide decorative characters from screen readers
← Previous message | Next message →
On 13/08/11 06:57, John Foliot wrote:
> Yes, I agree that screen readers (NVDA has the same behavior) shouldn't
> real aloud :before or :after pseudo-selector characters. We have a
> precedent here in that you cannot copy and paste those same characters
> from the browser screen (they are treated like background images) and
> screen readers should treat them the same way as well, IMHO.
>
> Anyone disagree, and if so why (please)?
I tend to agree with you, John, and foresee this possibly becoming a
thorny issue as the current draft of "Implementing UAAG 2.0"
(http://www.w3.org/TR/IMPLEMENTING-UAAG20/#sc-414) also suggests that
user agents should make CSS generated content available to accessibility
APIs:
"In user agents today, an author may inject content into a web page
using CSS (generated content). This content is written to the screen and
the CSS DOM. The user agent does not expose this generated content from
the CSS-DOM (as per CSS recommendation) to the platform accessibility
API or to the HTML-DOM. This generated content is non-existent to an
assistive technology user. The user agent should expose all information
from all DOMs to the platform accessibility API."
I wonder if browsers should then also be making such generated content
selectable for copy and paste?
Personally, I was happy thinking of CSS as being just for presentation
and style, and not also the creation of actual content.
Jason Kiss
From: Benjamin Hawkes-Lewis
Date: Sat, Aug 13 2011 3:48AM
Subject: Re: hide decorative characters from screen readers
← Previous message | Next message →
On Sat, Aug 13, 2011 at 2:14 AM, Jason Kiss < = EMAIL ADDRESS REMOVED = > wrote:
> On 13/08/11 06:57, John Foliot wrote:
>> Yes, I agree that screen readers (NVDA has the same behavior) shouldn't
>> real aloud :before or :after pseudo-selector characters. We have a
>> precedent here in that you cannot copy and paste those same characters
>> from the browser screen (they are treated like background images) and
>> screen readers should treat them the same way as well, IMHO.
>>
>> Anyone disagree, and if so why (please)?
>
> I tend to agree with you, John, and foresee this possibly becoming a
> thorny issue as the current draft of "Implementing UAAG 2.0"
> (http://www.w3.org/TR/IMPLEMENTING-UAAG20/#sc-414) also suggests that
> user agents should make CSS generated content available to accessibility
> APIs
WAI-ARIA, which is in CR, makes this a requirement:
http://www.w3.org/TR/wai-aria/roles#namecalculation
See also:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13668
> I wonder if browsers should then also be making such generated content
> selectable for copy and paste?
Copy and paste is very idiosyncratically implemented, but already does
include some generated content.
--
Benjamin Hawkes-Lewis
From: Yves Serrano
Date: Mon, Aug 15 2011 4:33AM
Subject: Re: hide decorative characters from screen readers
← Previous message | Next message →
Hi
thanks for all the feedback.
> Vincent Young wrote:
> both users or just hides content from visual users. I believe the
> solution is to use role="presentation"
> ...
> Use an in-line image that is a bit larger than what you need and has empty
> alt (alt=""). Then, incorporate some progressive techniques that allow
> the image to scale.
I think I will go with a <li> background image which was my first idea, it's the easiest to implement.
I would have preferred a scalable solution, to have a more general purpose technique for this problem,
but the "old" layout where I need it doesn't scale. Otherwise I would use the separate Images like suggest with progressive techniques.
I was curious if there was a more elegant/simpler solution than that.
Perhaps when SVG inline is supported by the most common browsers I could use that.
The role="presentation" would be the thing I was looking for but it doesn't seem to be implemented in JAWS (is it implemented in others?),
but it's good to know for the future.
I only want to hide the decorative character in a list, I think there it makes sense.
For non list links I agree that it makes sense to have the spoken separator.
It also right that this is not one of the most important things to do when you make a website accessible.
So resources spent in a complicated solution for this, should be better spent in other parts of the webpage :-).
The behavior of the browsers is very different with pseudo elements and copy&paste.
You can't select the text directly in the Browsers IE9, FF5, Safari5.
You can multiline select the text in Safari and IE9, but not in Firefox.
IE9 even copies it, Safari not. Firefox is the most consistence does't selects (direct & multiline) it and doesn't copies it.
> Jason Kiss wrote:
> ...
> Personally, I was happy thinking of CSS as being just for presentation
> and style, and not also the creation of actual content.
I overall argue with that.
One use case I found a bit against this, is with a responsive table approach.
See http://css-tricks.com/9096-responsive-data-tables/ here the table header content is replicated, to make it more accessible to small screens.
But this is only an edge case.
regards Yves
From: Jason Kiss
Date: Wed, Aug 17 2011 2:48AM
Subject: Re: hide decorative characters from screen readers
← Previous message | No next message
On 15/08/11 22:35, Yves Serrano wrote:
>> Jason Kiss wrote:
>> ...
>> Personally, I was happy thinking of CSS as being just for presentation
>> and style, and not also the creation of actual content.
> I overall argue with that.
> One use case I found a bit against this, is with a responsive table approach.
> See http://css-tricks.com/9096-responsive-data-tables/ here the table header content is replicated, to make it more accessible to small screens.
> But this is only an edge case.
Thanks for that example, Yves. In the case of the responsive table
approach, I'd agree, and take the opportunity to refine my statement to
say that I don't think CSS should be used to add meaningful content that
isn't otherwise already available in some way on the page. In the case
of the responsive table, the column headers are already there, so simply
replicating the headers via CSS content I wouldn't consider an all-out
creation of new actual content.
That said, with your example you also afforded me the opportunity to
rethink my position on CSS content added with :after and :before and
whether or not screen readers should read it. I'm now inclined to think
that, as long as CSS is not misused to add entirely new content the
meaning or intent of which is not otherwise unavailable with CSS off or
with some user stylesheet that overrides the relevant author styles,
screen readers should be reading that generated content (and
additionally, that browsers should likely provide some facility for
copying/pasting that same content). The responsive data tables are a
good example in this regard as, in NVDA and VoiceOver at any rate, the
replicated column headers are read aloud, and make interacting with the
responsive table a reasonable experience.
Jason