RE: screen reader reporting of negative values

Hi Adam,

Your initial report does cause some concern, yet Jonathan is not reporting the same findings.  Most significantly to me however is that while you are noting a “JAWs” problem, you have not indicated which browser(s) this is manifesting in.  Can you report to us the version of JAWs you are using, as well as which browser(s) (including version number) you are using in your testing?  Thanks in advance.

JF

From: Jonathan Avila [mailto:jon.avila@ssbbartgroup.com]
Sent: Monday, August 19, 2013 6:15 PM
To: renrez; w3c-wai-ig@w3.org
Subject: RE: screen reader reporting of negative values


>  JAWS however appears to ignore the standard dash (-),


JAWS 14.5005 works correctly (announces minus) with every punctuation level including “none”.

Jonathan

From: renrez [mailto:renrez@renrez.com<mailto:renrez@renrez.com>]
Sent: Monday, August 19, 2013 8:38 PM
To: w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>
Subject: RE: screen reader reporting of negative values


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<mailto:john.foliot@chase.com>]

Sent: Monday, August 19, 2013 3:45 PM

To: Jennifer Sutton; w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>Subject: 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.



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 12:19:11 UTC