- From: Sailesh Panchang <sailesh.panchang@deque.com>
- Date: Wed, 18 Mar 2020 10:36:30 -0400
- To: w3c-wai-ig@w3.org
Support for INS and DEL have been around for a while with JAWS and NVDA and have now got better with Firefox and Chrome: See http://mars.dequecloud.com/demo/example/Em-Strong-Del-InsTags.htm In my opinion, browser / AT makers should be encouraged to add support for native HTML elements and attributes when found lacking instead of adding ARIA roles / attributes and suggesting they should support those. Best wishes, Sailesh On 3/17/20, alands289@gmail.com <alands289@gmail.com> wrote: > Léonie. > > > > Thanks, this is very helpful. > > > > Alan Smith > > > > From: Léonie Watson > Sent: Tuesday, March 17, 2020 5:21 PM > To: alands289@gmail.com; Char Easter; Matt King; Phill Jenkins > Cc: w3c-wai-ig@w3.org; Evan Cordulack > Subject: Re: Question on Ins and Del - : Re: Or! - RE: Re: how to code > strikethroughs for a screenreader > > > > I haven't read through this thread, so apologies if this has already > > been mentioned, but the March update for Jaws 2020 adds support for > > content marked up using the HTML <del> and <ins> elements [1]. Support > > is in firefox and the Chromium browsers (new Edge, Brave, Yandex etc.) > > though not old Edge or IE. > > > > Jaws uses a different voice to announce the start and end of the deleted > > or inserted text. So for the following example Jaws says "Deletion", > > "this has been deleted", "Deletion end". > > > > <p>In this sentence <del>this text has been deleted</del> but not this > > text.</p> > > > > Similarly, in the following example Jaws announces "Insertion", "this > > text has been inserted", "Insertion end". > > > > <p>In this sentence <ins>this text has been inserted</ins> but this text > > was here already.</p> > > > > It's a very useful addition I think. > > > > > > Léonie. > > > > > > > > [1] > > https://support.freedomscientific.com/Downloads/JAWS/JAWSWhatsNew#Enhancements > > > > > > On 17/03/2020 19:28, alands289@gmail.com wrote: > >> Matt, > >> > >> I’m not quite clear on ins and del. > >> > >> Are these terms that will be announced for the strikethrough type > >> annotation? > >> > >> If so, has it been tested with blind users to see if this properly > >> communicates something that they will understand. > >> > >> I have no understanding of what insert and delete mean. > >> > >> Alan Smith > >> > >> *From: *Char Easter <mailto:ceaster@seattletimes.com> > >> *Sent: *Tuesday, March 17, 2020 1:28 PM > >> *To: *Matt King <mailto:a11ythinker@gmail.com>; alands289@gmail.com > >> <mailto:alands289@gmail.com>; Phill Jenkins <mailto:pjenkins@us.ibm.com> > >> *Cc: *w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org>; Evan Cordulack > >> <mailto:ecordulack@seattletimes.com> > >> *Subject: *Re: Or! - RE: Re: how to code strikethroughs for a screenreader > >> > >> Thanks all for the input and quick action. > >> > >> *From: *Matt King <a11ythinker@gmail.com> > >> *Date: *Wednesday, March 4, 2020 at 10:20 AM > >> *To: *"alands289@gmail.com" <alands289@gmail.com>, 'Phill Jenkins' > >> <pjenkins@us.ibm.com>, Char Easter <ceaster@seattletimes.com> > >> *Cc: *"w3c-wai-ig@w3.org" <w3c-wai-ig@w3.org> > >> *Subject: *RE: Or! - RE: Re: how to code strikethroughs for a screenreader > >> > >> Scope of ARIA 1.3 includes new semantics related to annotations, which > >> includes comments on revisions marked up with ins and del elements. > >> > >> As part of adding these semantics to ARIA 1.3, we will also draft > >> guidance for the ARIA Authoring Practices and add canonical examples of > >> implementations. > >> > >> After the APG Task Force has consensus on the example implementations, > >> we will add screen reader tests for the semantics to the ARIA and > >> Assistive Tehcnology (aria-at) project. > >> > >> So, by end of year, we should have an end-to-end understanding of any > >> gaps in this space and a clear path to full support. > >> > >> Side note: testing of implied ARIA semantics in native HTML is on the > >> 2021 roadmap for aria-at. However, ins and del will certainly get > >> covered by the annotations work, which should all happen this year. > >> > >> Matt > >> > >> *From:* alands289@gmail.com <alands289@gmail.com> > >> *Sent:* Tuesday, March 3, 2020 6:22 PM > >> *To:* Phill Jenkins <pjenkins@us.ibm.com>; Char Easter > >> <ceaster@seattletimes.com> > >> *Cc:* w3c-wai-ig@w3.org > >> *Subject:* Or! - RE: Re: how to code strikethroughs for a screenreader > >> > >> Or! > >> > >> Generally, we should make our elements communicate to “all”. > >> > >> Your points are all good. > >> > >> If there is a known limitation then as those that strive to support > >> accessibility it is our job to make things work for screen reader users > >> or any other disability type if there is a know limitation that does > >> have a solution. > >> > >> I’m not aware of a JAWS bug for a lack of supporting strike-through or > >> the other styles you mentioned. > >> > >> Not everything will be supported by screen readers, so we have to have a > >> method to make it work. > >> > >> Also, there are many other screen readers besides JAWS that we must > >> support as well. > >> > >> None that I know of announce the strike-through. > >> > >> I’ve found a way that works and have communicated it to countless > >> clients and they all seem happy with my suggested fix. > >> > >> Its just one of the values of years of experience that we can acquire > >> solutions to problems and share them with others to make them successful. > >> > >> For those that use strike-through, once they know a way to make it work, > >> they just add it to their own company design documentation or library > >> and they have a solution that they can use. > >> > >> Regards, > >> > >> Alan Smith > >> > >> *From: *Phill Jenkins <mailto:pjenkins@us.ibm.com> > >> *Sent: *Tuesday, March 3, 2020 6:32 PM > >> *To: *alands289@gmail.com <mailto:alands289@gmail.com>; Char Easter > >> <mailto:ceaster@seattletimes.com> > >> *Cc: *w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> > >> *Subject: *Re: how to code strikethroughs for a screenreader > >> > >> What? > >> generally, we should *not* be hacking things just for screen readers. > >> Did anyone ask the screen reader developers if they support > >> strike-through? ask about *super-script*, /sub-script, italics, etc. > >> /while you're asking. > >> > >> If it isn't supported by the screen reader, then its a screen reader > >> bug! that needs to be fixed / supported. > >> > >> but I believe it is supported via a user setting. For example, See > >> JAWS Techniques for Examining Text Formatting > >> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoccenter.freedomscientific.com%2Fdoccenter%2Fdoccenter%2Frs25c51746a0cc%2F2012-06-20_textformatting%2F02_textformatting.htm&data=02%7C01%7Cceaster%40seattletimes.com%7Ce60ad63c06864be0a66608d7c068b52e%7Cfc2b8476b7f0473d82fbe0a89fd99855%7C0%7C0%7C637189428258107898&sdata=hN6qkXo753hJrL62j8ibrLUOV88inOpV%2BjIRjpA%2FBxk%3D&reserved=0> > >> > >> However, I'm not sure JAWS supports styling like > >> "text-decoration:line-through" because it may not really be a text > >> attribute. > >> > >> From 2005, a thread said: > >> Now, with my settings on "attributes", my JAWS is also reading > >> "strikethrough". > >> If this is not clear, or what you get is not what you expected, please > >> consult your help for JAWS. > >> ___________ > >> Regards, > >> Phill Jenkins > >> > >> > >> Inactive hide details for ---03/03/2020 05:08:32 PM---Char, That is a > >> very interesting question. Here is what I do that wor---03/03/2020 > >> 05:08:32 PM---Char, That is a very interesting question. Here is what I > >> do that works great. On the product > >> > >> From: <alands289@gmail.com <mailto:alands289@gmail.com>> > >> To: Char Easter <ceaster@seattletimes.com > >> <mailto:ceaster@seattletimes.com>>, "w3c-wai-ig@w3.org > >> <mailto:w3c-wai-ig@w3.org>" <w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org>> > >> Date: 03/03/2020 05:08 PM > >> Subject: [EXTERNAL] RE: how to code strikethroughs for a screenreader > >> > >> > >> > >> > >> Char, > >> > >> That is a very interesting question. > >> > >> Here is what I do that works great. > >> > >> On the product pages with strikethrough text, strikethrough text is not > >> announced by screen readers. Therefore, non-visual users will not have > >> communicated to them that the original price is no longer valid and thus > >> “striked through”. The text will need further coding. > >> How is this a problem: > >> Non-visual users will not understand what the two different prices mean > >> when the screen reader announces them. This may be during a read all of > >> the page, a virtual read of the text or text announced from a link. > >> How to fix: > >> Add a span before the strike through amount with the words original > >> price (or equivalent term). Have the span be your supported > >> visuallyhidden class so it does not show on the screen. > >> <span class=""visuallyhidden"">Original price</span> > >> <span style=""text-decoration: line-through"">$70.00</span> > >> > >> I hope this helps. > >> > >> Alan Smith > >> > >> *From: *Char Easter <mailto:ceaster@seattletimes.com>* > >> Sent: *Tuesday, March 3, 2020 5:31 PM* > >> To: *w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org>* > >> Subject: *how to code strikethroughs for a screenreader > >> > >> Hello, > >> > >> Is there a way a screen reader can read a strikethrough on text so a > >> screen reader user can interpret the meaning/intent? > >> > >> Thanks, > >> > >> *Char Easter* > >> UX Designer at The Seattle Times > >> p: 206.464.2945 > >> e: ceaster@seattletimes.com <mailto:ceaster@seattletimes.com> > >> m: 206.779.2427 > >> > >> > > > > -- > > Director @TetraLogical > > -- Sailesh Panchang Principal Accessibility Consultant Deque Systems Inc 381 Elden Street, Suite 2000, Herndon, VA 20170 Mobile: 571-344-1765
Received on Wednesday, 18 March 2020 14:36:46 UTC