E-mail List Archives
Thread: Strikethrough Content with Screen Readers
Number of posts in this thread: 18 (In chronological order)
From: Vivek.Gaikwad
Date: Fri, Nov 19 2010 7:48AM
Subject: Strikethrough Content with Screen Readers
No previous message | Next message →
While reading the strikethrough element, JAWS does not recognize it
differently and thus user is not informed about the striked content.
One way to solve this is, change JAWS settings, so that it reads it in
different tone.
Eg: New Price<del>30</del>20$. In this case, if JAWS settings are not
done, it reads it as "New Price 3020$". This is incorrect information.
If we change the settings, JAWS reads 30 in different tone - high pitch
voice and the user will come to know about the content. Is there any way
the developers of the content can do anything, so that the screen reader
user do not need to change the settings and still get the correct
information?
Is there any other screen reader apart from JAWS, which takes care of
such issues?
peace, veiky
This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information.
If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly
prohibited and may be unlawful.
From: steven
Date: Fri, Nov 19 2010 8:21AM
Subject: Re: Strikethrough Content with Screen Readers
← Previous message | Next message →
Hi Veiky,
I'm not familiar with this behaviour (nor am I a personal fan of the del
tag), but could adding a description or title attribute to the del tag, be
used to notify the user of what has changed and why!? If not, I think there
quickly becomes an argument as to why you should alert the user of the
deleted content at all.
Steven
From: Jared Smith
Date: Fri, Nov 19 2010 8:57AM
Subject: Re: Strikethrough Content with Screen Readers
← Previous message | Next message →
On Fri, Nov 19, 2010 at 7:45 AM, < = EMAIL ADDRESS REMOVED = > wrote:
> Is there any way
> the developers of the content can do anything, so that the screen reader
> user do not need to change the settings and still get the correct
> information?
No. Nor should they. It's the responsibility of assistive technology
to properly handle the most simple of markup. And it's our
responsibility to demand that they do.
We're reaching a *very* critical time on the web where if AT does not
step up and start handling basic HTML, ARIA, and (especially) HTML5
markup (which has both <del> and <ins> and much more) that users of
these technologies are going to quickly begin having very poor
experiences on the web despite web authors creating highly accessible
and well marked-up content. </rant>
Jared Smith
WebAIM
From: Pooja.Nahata
Date: Fri, Nov 19 2010 9:09AM
Subject: Re: Strikethrough Content with Screen Readers
← Previous message | Next message →
I second Jared thoughts.
I am of the opinion if we go down this route of adding additional
information in the attributes - we would be over doing accessibility and
won't be a able to define how much is too much.
If proper markup is used, AT should pass the same information to the
user like a sighted user would receive.
Regards
Pooja Nahata - Accessibility Practice Lead
Cognizant Technology Solutions
From: steven
Date: Fri, Nov 19 2010 9:45AM
Subject: Re: Strikethrough Content with Screen Readers
← Previous message | Next message →
There is much about current browsers and AT that infuriates me too Jared,
but in this instance, I think if there is a reason to include redundant
content using a del tag (as in, it never made it to final draft) then there
is case to explain to the user why it is no longer part of the content ...
AT can no more do that than it can guess what every image alt text should
be.
Regards,
Steven
From: Bevi Chagnon | PubCom
Date: Fri, Nov 19 2010 10:09AM
Subject: Re: Strikethrough Content with Screen Readers
← Previous message | Next message →
Jared wrote:
" No. Nor should they. It's the responsibility of assistive technology to
properly handle the most simple of markup. And it's our responsibility to
demand that they do. "
I agree. Both sides have their responsibilities.
But I wonder if lack of funding for research and development (R & D) is
preventing our A.T. developers from putting more power behind their software
and hardware.
Would federal grants help fund these efforts and get better products into
the hands of our A.T. users?
Our U.S. federal government gives major defense contractors billions of
dollars every year to design faster fighter jets and bigger bombs. I wonder
if we could divert a couple million of those dollars to our A.T. companies
who would create products that helped people rather than killed them.
Oh wait...I'm sorry.
There I go again, talking politics on a list.
My apologies, but I do live and work in Washington, D.C. so politics comes
with my job!
--Bevi Chagnon
: : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : :
Bevi Chagnon | PubCom | = EMAIL ADDRESS REMOVED = | 301-585-8805
Government publishing specialists, trainers, consultants | print, press,
web, Acrobat PDF & 508
Online at the blog: It's 2010. Where's your career heading?
www.pubcom.com/newslette
From: Bevi Chagnon | PubCom
Date: Fri, Nov 19 2010 10:21AM
Subject: Re: Strikethrough Content with Screen Readers
← Previous message | Next message →
Vieky wrote:
" Eg: New Price<del>30</del>20$. In this case, if JAWS settings are not
done, it reads it as "New Price 3020$". This is incorrect information. "
Another way to address this problem is to restructure the sentence when
possible. Use just plain old-fashioned grammar and editing techniques rather
than force technology to fit the situation.
In Vieky's example, it would become:
Was $30, now reduced to $20.
If you're selling a product, that's a much more effective sales method than
the technical accessibility mark-up.
Another situation where I've found screen readers mis-read the content when
an n-dash or hyphen is used in a series. Correct American English grammar
rules would require n-dashes in these examples:
9-5 business hours.
50-100 people can be accommodated in the auditorium.
open Monday-Friday.
To ensure A.T. reads these samples correctly, write out the "to" and
"through" rather than use n-dashes or hyphens:
9 to 5 business hours.
50 to 100 people.
open Monday through Friday.
They're now guaranteed to be read correctly by all people, whether they're
using an A.T. technology or not.
--Bevi Chagnon
: : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : :
Bevi Chagnon | PubCom | = EMAIL ADDRESS REMOVED = | 301-585-8805
Government publishing specialists, trainers, consultants | print, press,
web, Acrobat PDF & 508
Online at the blog: It's 2010. Where's your career heading?
www.pubcom.com/newsletter
From: Randall Pope
Date: Fri, Nov 19 2010 2:09PM
Subject: Re: Strikethrough Content with Screen Readers
← Previous message | Next message →
Vivek and all,
Using different tones to read the different prices, is no help for the
people who cannot hear, mainly the deaf-blind people who depends solely on
braille display to read the web pages.
Simple html markup is the best way to go to make it accessible. As for the
strike out, i think it would be best to use good proper language writing to
address the strike out issue.
<rant>Why does most developers focus accessible issues for the hearing
blind only and not all people with disabilities? We have a good number of
senior citizens who are having issues with their vision and hearing
losses.</rant>
<Jared>Thank for the humor thoughts. Grinning</Jared>
Randall Pope
American Association of the Deaf-Blind (AADB)
From: Christophe Strobbe
Date: Fri, Nov 19 2010 2:39PM
Subject: Re: Strikethrough Content with Screen Readers
← Previous message | Next message →
Hi Bevi,
At 18:05 19/11/2010, Bevi Chagnon | PubCom wrote:
>(...) But I wonder if lack of funding for research and development (R & D) is
>preventing our A.T. developers from putting more power behind their software
>and hardware.
As far as I know, one of the problems for AT developers was the lack
of comprehensive accessibility APIs (at least on Windows), so AT
developers had to use call other APIs (which may be
application-specific), and sometimes even resort to video driver
patching techniques, to build on off-screen model and present
information to the user.
Some APIs (e.g. the application-specific APIs) change when a new
version of an operating system or an application is released, so AT
developers need to waste time adapting to the new APIs. This time is
just spent on catching up instead of making progress.
A few years ago, Microsoft introduced a new accessibility framework
called UI Automation. Hopefully, this will improve the situation...
>Would federal grants help fund these efforts and get better products into
>the hands of our A.T. users?
Don't know. Aren't such funds meant for innovation? Implementing
WAI-ARIA in AT may count as innovation, but plain old HTML elements
and attributes?
>Our U.S. federal government gives major defense contractors billions of
>dollars every year to design faster fighter jets and bigger bombs. I wonder
>if we could divert a couple million of those dollars to our A.T. companies
>who would create products that helped people rather than killed them.
Good idea, since the military creates customers for AT - i.e. by
making people disabled.
Best regards,
Christophe
>Oh wait...I'm sorry.
>
>There I go again, talking politics on a list.
>My apologies, but I do live and work in Washington, D.C. so politics comes
>with my job!
>
>--Bevi Chagnon
>
>: : : : : : : : : : : : : : : : : : :
>: : : : : : : : : : : : :
>Bevi Chagnon | PubCom | = EMAIL ADDRESS REMOVED = | 301-585-8805
>Government publishing specialists, trainers, consultants | print, press,
>web, Acrobat PDF & 508
>Online at the blog: It's 2010. Where's your career heading?
>www.pubcom.com/newslette
--
Christophe Strobbe
K.U.Leuven - Dept. of Electrical Engineering - SCD
Research Group on Document Architectures
Kasteelpark Arenberg 10 bus 2442
B-3001 Leuven-Heverlee
BELGIUM
tel: +32 16 32 85 51
http://www.docarch.be/
Twitter: @RabelaisA11y
---
"Better products and services through end-user empowerment"
www.usem-net.eu - www.stand4all.eu
---
Please don't invite me to Facebook, Quechup or other "social
networks". You may have agreed to their "privacy policy", but I haven't.
From: Jared Smith
Date: Fri, Nov 19 2010 9:57PM
Subject: Re: Strikethrough Content with Screen Readers
← Previous message | Next message →
On Fri, Nov 19, 2010 at 2:08 PM, Randall Pope wrote:
> Using different tones to read the different prices, is no help for the
> people who cannot hear, mainly the deaf-blind people who depends solely on
> braille display to read the web pages.
A relatively easy and universally accessible system would be to simply
allow the user to specify whether they want content that has been
stricken to be read in a different pitch or intonation, or to have it
identified explicitly by reading (or outputting to braille) "begin
deletion" before and "end deletion" after (or "insertion" in the case
of <ins>).
> Simple html markup is the best way to go to make it accessible.
I agree.
> As for the
> strike out, i think it would be best to use good proper language writing to
> address the strike out issue.
But this contradicts your previous statement. The best way to make it
accessible is to allow the author to write it however they feel is
best using proper markup, and have AT support this standard mark-up.
Gone are the days when we can and should ask authors to stop using
standard and well-accepted markup and techniques because some AT has
yet to support markup that's been in existence for 12 years. I find it
interesting that we wring our hands about assistive technology and
ARIA and HTML5 support when most screen readers don't handle semantic
markup as simple as <strong> yet.
Jared
From: Terrill Bennett
Date: Sat, Nov 20 2010 1:45PM
Subject: Re: Strikethrough Content with Screen Readers
← Previous message | Next message →
From a previous post:
> We're reaching a *very* critical time
> on the web where if AT does not step
> up and start handling basic HTML,
> ARIA, and (especially) HTML5 markup
> (which has both <del> and <ins> and
> much more) that users of these
> technologies are going to quickly
> begin having very poor experiences on
> the web despite web authors creating
> highly accessible and well marked-up
> content.
ARIA and HTML5 are drafts, not finalized recommendations. Drafts are
moving targets. Read as Philippe Le Hegaret, W3C interaction domain
leader, warns on the early adoption of HTML5 and other issues with
the specification:
http://www.infoworld.com/d/developer-world/w3c-hold-html5-in-websites-041
Mr. Le Hegaret states that there will be changes to APIs. As any
project manager can tell you, going back and changing existing code
due to changes in requirements is one of the most expensive
propositions known. And to a developer, retrofitting code is not
considered an overly-exciting task; there's no better way to rid your
team of good talent than repeatedly assigning them to maintenance.
For a moment, please consider the number of ARIA roles, their
defaults, options, relationships and hierarchy:
http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles
In light of the warning against the early adoption of HTML5, isn't it
too early to expect A.T. to implement the ARIA draft?
If we think that A.T. should be supporting these drafts fully, then
how much more are we willing to pay for a copy JAWS so Freedom
Scientific can add the necessary resources? How many more volunteers
will the NVDA Project need?
To write <del>something</del> or role="something" is exponentially
easier than developing the code in A.T. to support it, and fixing the
code when the requirement changes.
-- terrill --
From: Patrick H. Lauke
Date: Sat, Nov 20 2010 2:09PM
Subject: Re: Strikethrough Content with Screen Readers
← Previous message | Next message →
On 20/11/2010 20:44, Terrill Bennett wrote:
> From a previous post:
>
> > We're reaching a *very* critical time
> > on the web where if AT does not step
> > up and start handling basic HTML,
> > ARIA, and (especially) HTML5 markup
> > (which has both<del> and<ins> and
> > much more) that users of these
> > technologies are going to quickly
> > begin having very poor experiences on
> > the web despite web authors creating
> > highly accessible and well marked-up
> > content.
>
> ARIA and HTML5 are drafts, not finalized recommendations. Drafts are
> moving targets. Read as Philippe Le Hegaret, W3C interaction domain
> leader, warns on the early adoption of HTML5 and other issues with
> the specification:
> http://www.infoworld.com/d/developer-world/w3c-hold-html5-in-websites-041
>
> Mr. Le Hegaret states that there will be changes to APIs. As any
> project manager can tell you, going back and changing existing code
> due to changes in requirements is one of the most expensive
> propositions known. And to a developer, retrofitting code is not
> considered an overly-exciting task; there's no better way to rid your
> team of good talent than repeatedly assigning them to maintenance.
>
> For a moment, please consider the number of ARIA roles, their
> defaults, options, relationships and hierarchy:
> http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles
>
> In light of the warning against the early adoption of HTML5, isn't it
> too early to expect A.T. to implement the ARIA draft?
>
> If we think that A.T. should be supporting these drafts fully, then
> how much more are we willing to pay for a copy JAWS so Freedom
> Scientific can add the necessary resources? How many more volunteers
> will the NVDA Project need?
>
> To write<del>something</del> or role="something" is exponentially
> easier than developing the code in A.T. to support it, and fixing the
> code when the requirement changes.
Keeping in mind though that ins and del, specific to this thread, have
been in circulation since HTML4 / 1999, ample time for AT to at least
start supporting THAT.
P
--
Patrick H. Lauke
From: Vivek.Gaikwad
Date: Sun, Nov 21 2010 10:42PM
Subject: Re: Strikethrough Content with Screen Readers
← Previous message | Next message →
Jared, I agree that the AT vendors should take care of such issues in the newer versions and we need to ask for it. But, at such instance if we do not deliver some operative solution, it's the end user who is going to suffer for whom are creating accessible content.
@ Bevi: Changing the sentence framing would be the last option I could think of, as it is not going to help in all the scenarios. But yes, we need to go with it if we don't see any other option, which is the case here :) At least the end user will get the correct information.
peace, veiky
From: Priti
Date: Mon, Nov 22 2010 3:15AM
Subject: Re: Strikethrough Content with Screen Readers
← Previous message | Next message →
Hi All,
I completely agree with Jared, it is the responsibility of AT vendors to
ensure that information provided using markup is read out effectively. But I
have a point to make here that SuperNova reads strike-through content
perfectly. Its time that we start testing with multiple screen readers and
not only depend on JAWS for A11y testing as is the case of web browsers.
Thanks & Regards,
Priti Rohra
Head Accessibility Testing
Net Systems Informatics (India) Pvt. Ltd. & BarrierBreak Technologies
Web: www.n-syst.com | www.barrierbreak.com
Blog: www.barrierbreak.com/blog
Please don't print this email unless you really need to. This will preserve
trees on our planet.
From: Hoffman, Allen
Date: Mon, Nov 22 2010 7:39AM
Subject: Re: Strikethrough Content with Screen Readers
← Previous message | Next message →
Don't focus on the screen reader, you are not in control of that for the
end-user.
Focus on coding in consistent fashion. If you need users to know
something specific about the pricing by using the specific tag, identify
it textually also. This will be interpretable by all until a more
supported method based only on the tagging becomes available.
From: Cliff Tyllick
Date: Mon, Nov 22 2010 4:33PM
Subject: Re: Strikethrough Content with Screen Readers
← Previous message | Next message →
<rant>As you might be able to tell if you follow @clifftyll on Twitter, I am baffled by the decision process that seems to be used by some of the teams (well, one of the teams) involved in setting Web standards. Specifically, decisions seem to be made on the basis of looking backwards, not forwards.
By "looking backwards," I mean basing decisions on the results produced by people who have already used these tools. In making these decision, they focus on the answers to three questions (perhaps more, but I can think of three quickly):
- Did authors and developers have reasons to use this tool -- in other words, were there use cases in the "real world"?
- Have they used the tool frequently?
- Have they used it in the way we intended?
By "looking forwards," I mean looking ahead to all the reasons people might use the Internet. This approach would ask questions like these:
- What kind of content do people need to publish?
- What use cases arise with that content?
- What features do we need to create to support that content?
- How can we teach people to use those features properly?
If we don't look ahead and prepare the way for the content people produce, either they will never use the Web for that content or, more likely, they will misuse whatever we do prepare as they try to retrofit it to their content.</rant>
Now in this case, that means we need to think of all the potential use cases for strikeout and insert:
- As in Vieky's example, in advertisements, to show price reductions.
- Authors and their editors, perhaps?
- How about people who are working out contract language with their attorneys?
- Teams of people who are drafting international standards and guidelines?
- And redline and strikeout -- the word-processing equivalent of <del> and <ins> -- are the standard convention for legislation, rule development, and other similar processes throughout the United States and, I imagine, many other countries.
There might be others, but those are a good start. So do the first question is, "Does markup language need tags to support these use cases?"
Bevi suggested that we might not, at least not in all cases, if we rewrite the content: "Was $30; now $20." That might work in an ad, but even there it would be problematic. $<del>30</del>20 could be much more compelling visually, so I have a hard time believing that every advertising executive would be okay with softening the punch by using words instead.
And I hope it's obvious to us all that rewriting is not possible in the other cases. It would be hard to do, and it would be even harder for both humans and software to interpret the results. So we need some kind of markup.
The <del> and <ins> tags exist and would meet this need. Later let's consider whether we need attributes to associate with these tags. So now let's think of how assistive technology should handle it.
One option is for screen readers to change the tone. As Randall pointed out, this would not help people who are deaf/blind. And considering the number of different tones that would be needed, this approach would place an undue cognitive burden on the listener. I count at least these 12 conditions:
- Four kinds of original text: plain, with emphasis, strong, and with strong emphasis.
- The same four kinds of deleted text.
- The same four kinds of inserted text.
So assistive technology will need to convey several different kinds of information to the listener for each deletion and insertion:
- the location where the change begins.
- the type of change.
- the wording associated with the change.
- the type of formatting change, if any.
- the location where the change ends.
So it seems that attributes of the <ins> and <del> tags would be useful.
There might be comments or questions associated with the changes, too. I don't know if HTML5 has a tag for comments other than footnotes and endnotes. I would have to read the spec to figure it out.
And just as people using Word have a variety of options for displaying an edited document -- just the original; the original plus changes; just the final; the final showing changes -- and a number of ways to interact with the document -- for example, to read only the edits and skip from one edit to the next; or to do the same with the comments -- I think it would be important to support those capabilities for all people in HTML5.
Indeed, it sounds like stuff a working group should consider carefully. If more people are going to use HTML as an authoring tool, then we are going to need for HTML5 and assistive technologies to robustly support the kind of work those people need to do.
And <ins>/<del> is just the beginning.
Ok, so maybe I misplaced the </rant> tag. But now I'm done.
Cliff
Cliff Tyllick
Usability assessment coordinator
Agency Communications Division
Texas Commission on Environmental Quality
512-239-4516
= EMAIL ADDRESS REMOVED =
From: Randall Pope
Date: Wed, Nov 24 2010 10:09AM
Subject: Re: Strikethrough Content with Screen Readers
← Previous message | Next message →
Jared,
You do have a good point. You're right that I contradicted myself on my
last statement. The price I pay for not paying attention. Unfortunately
for me, I have a failure to communicate with coffee. Grinning.
In an ideal world, Im in agreement that the industries need to "catch up"
with the latest web technologies being employed on the websites.
However that has not happens as most assistive technology industries for
people with disabilities are a bit behind, especially related to specialized
technology design or devices. The reason is obvious: not enough money (or
none at all) are going to researching and development these products.
More to the point, many of the "taking only" devices are inaccessible for
deaf-blind people who cannot hear and depends on braille to access the
information. I personally cannot hear the speech being spoken and depends
in readjusting the setting on the computer for me to view the web.
Again, I do support that the industries need to stay with the latest web
technology. I just wish they would broaden their product or devices to
accommodate people who are totally blind with severe hearing losses. Good
example: the growing population of Senior Citizens losing their hearing and
sight.
BTW, on behalf of AADB, I have filed our comments in response to the FFC's
call for comments on the distribution of the Deaf-Blind Technology
equipment. It does contain some issues related in accessing the web. It's
filed under 10-210 if anyone is interested in viewing the comments.
Happy Thanksgiving!
Randall Pope
AADB
From: ckrugman
Date: Sat, Nov 27 2010 4:57PM
Subject: Re: Strikethrough Content with Screen Readers
← Previous message | No next message
As these examples are common methods of writing in the English language and
it is understood when a screen reader reads open 9-5 why is it necessary? As
a screen reader user I think this is carrying things a bit more when wording
content.
Chuck
----- Original Message -----
From: "Bevi Chagnon | PubCom" < = EMAIL ADDRESS REMOVED = >
To: "'WebAIM Discussion List'" < = EMAIL ADDRESS REMOVED = >
Sent: Friday, November 19, 2010 9:18 AM
Subject: Re: [WebAIM] Strikethrough Content with Screen Readers
> Vieky wrote:
> " Eg: New Price<del>30</del>20$. In this case, if JAWS settings are not
> done, it reads it as "New Price 3020$". This is incorrect information. "
>
> Another way to address this problem is to restructure the sentence when
> possible. Use just plain old-fashioned grammar and editing techniques
> rather
> than force technology to fit the situation.
>
> In Vieky's example, it would become:
> Was $30, now reduced to $20.
>
> If you're selling a product, that's a much more effective sales method
> than
> the technical accessibility mark-up.
>
> Another situation where I've found screen readers mis-read the content
> when
> an n-dash or hyphen is used in a series. Correct American English grammar
> rules would require n-dashes in these examples:
> 9-5 business hours.
> 50-100 people can be accommodated in the auditorium.
> open Monday-Friday.
>
> To ensure A.T. reads these samples correctly, write out the "to" and
> "through" rather than use n-dashes or hyphens:
> 9 to 5 business hours.
> 50 to 100 people.
> open Monday through Friday.
> They're now guaranteed to be read correctly by all people, whether they're
> using an A.T. technology or not.
>
> --Bevi Chagnon
>
> : : : : : : : : : : : : : : : : : : :
> : : : : : : : : : : : : :
> Bevi Chagnon | PubCom | = EMAIL ADDRESS REMOVED = | 301-585-8805
> Government publishing specialists, trainers, consultants | print, press,
> web, Acrobat PDF & 508
> Online at the blog: It's 2010. Where's your career heading?
> www.pubcom.com/newsletter
>
>
>