W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2013

Re: screen reader reporting of negative values

From: Olaf Drümmer <olaf@druemmer.com>
Date: Tue, 20 Aug 2013 09:34:05 +0200
Cc: Olaf Drümmer <olaf@druemmer.com>
Message-Id: <E861ADFA-9560-4E55-8F1A-46E8630DDAA3@druemmer.com>
To: W3C WAI ig <w3c-wai-ig@w3.org>
Just a few thoughts from my side:

- accessibility is about semantics getting encoded right; em dash and similar characters would be completely wrong; the dash strictly speaking is wrong as well, nevertheless it is next to impossible for most users to get the minus sign right using the text entry mechanisms they have at their finger tips; we need to acknowledge that, and prepare ourselves; in the times where we only had a type writer, hardly anybody mixed a dash up with a minus sign, though sometimes context had to be taken into account; in those languages and scripts I know a sequence of digits, possibly with a comma or (decimal) point inside it, preceded with a dash like sign meant that I have a negative number in front of me; 

- avoid specialist tracks . hacks, like showing content to some, but not to others; this should always only be a last resort, but never recommended practice; 

- if there is a problem, fix the source, not the symptom; in this case, if some AT can't reproduce such content correctly or in a useful fashion, fix the AT, not the zillions of web pages and documents out there; please note, that this is not specific to JAWS.


Olaf



Am 20 Aug 2013 um 02:37 schrieb renrez <renrez@renrez.com>:

> Hi
> 
> I am working on this problem with Roger, from our testing to date NVDA is reading most variations correctly. JAWS however appears to ignore the standard dash (-), which has led to considering other alternatives like &#8722; and non HTML character methods. The following html character variations we have tested include:
> 
> 1. -
> 2. &mdash;
> 3. &#8722;
> 4. &minus;
> 5. &#8212;
> 
> We also tested these variations with and without a space between the html characters and the numeric value. 
> 
> The other method considered is adding <span>minus</span> before -$568.09 and hiding with absolute positioning, the downside is the minus text and dash can both be heard although that is preferred to a negative value that isn't identified at all.
> 
> &mdash; appears consistent/reliable in our testing as is inserting <span>minus</span> before the numeric value. These methods fall in line with John's point that the solution must work with a screen readers default settings.
> 
> Would appreciate any other suggestions to this problem.
> 
> 
> Thanks
> 
> Adam Zerner
> 
>  
>  
>  
>  
> On 2013-08-20 08:19, Jonathan Avila wrote:
> 
>> [John wrote]
>> continue to believe that we, as authors, carry a slightly heavier lift in
>> ensuring our clients are given the best user experience - this goes beyond
>> just "letter of the law" accessibility, and into what is the Best
>> Practice. (And lest anyone think I am being 'condescending' to non-sighted
>> users here, I believe Best Practices for optimum user experience crosses
>> all user-groups.)
>> 
>> We do however need to be careful to draw a line between this example that
>> includes financial data and the too often seen approach that good
>> intentioned but novice content authors make to fix mispronounced words.
>> For example, content authors will try to phonetically spell out words or
>> acronyms in alt text and CSS positioned off-screen text.  When this occurs
>> the text is not legible in braille, may be targeted to a particular speech
>> synthesizer, and is plain confusing when read a character at a time.  We
>> certainly do not want to encourage such a scenario.
>> 
>> Jonathan
>> 
>> -----Original Message-----
>> From: Foliot, John [mailto:john.foliot@chase.com]
>> Sent: Monday, August 19, 2013 3:45 PM
>> To: Jennifer Sutton; w3c-wai-ig@w3.orgSubject: RE: screen reader reporting of negative values
>> 
>> Jennifer Sutton wrote:
>>> I agree with Sailesh: As I see it, this is where the user has a responsibility as part of the :"accessibility contract." If you're looking at your finances, even if you don't know how to adjust your screen reader's verbosity, you better darned sure know how to navigate character by character to check for minus signs (not to mention being careful to check for correct reporting of numbers, if you suspect something is amiss). As far as I know, examining character by character *should* report *all* characters regardless of punctuation settings, at least in my experience of some, but not all, screen readers.
>> I principle, I agree, but with the following provisions:
>> 
>> 1) As part of the "accessibility contract" authors must ensure that
>> content is Perceivable and Understandable, thus this *is* an author issue
>> (Sailesh feels otherwise).
>> 
>> 2) There are multiple ways of visually rendering "a minus symbol" on
>> screen, as Roger noted in his initial post:
>>> I am interested in finding the best way to include negative values in a table. For example a table showing an overdrawn bank account or a temperature below zero (c or f). It seems that there is some variability in the level of screen reader (and/or browser) support for coded &mdash; and &#8212; or the standard keyboard dash.
>> I believe that it is important that authors understand which of those ways
>> works versus which introduces confusion, etc.
>> 
>> I continue to believe that we, as authors, carry a slightly heavier lift
>> in ensuring our clients are given the best user experience - this goes
>> beyond just "letter of the law" accessibility, and into what is the Best
>> Practice. (And lest anyone think I am being 'condescending' to non-sighted
>> users here, I believe Best Practices for optimum user experience crosses
>> all user-groups.)
>> 
>> JF
>> 
>> This transmission may contain information that is privileged,
>> confidential, legally privileged, and/or exempt from disclosure under
>> applicable law.  If you are not the intended recipient, you are hereby
>> notified that any disclosure, copying, distribution, or use of the
>> information contained herein (including any reliance thereon) is STRICTLY
>> PROHIBITED.  Although this transmission and any attachments are believed
>> to be free of any virus or other defect that might affect any computer
>> system into which it is received and opened, it is the responsibility of
>> the recipient to ensure that it is virus free and no responsibility is
>> accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as
>> applicable, for any loss or damage arising in any way from its use.  If
>> you received this transmission in error, please immediately contact the
>> sender and destroy the material in its entirety, whether in electronic or
>> hard copy format. Thank you.
>> 
Received on Tuesday, 20 August 2013 07:34:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:49 UTC