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]
*Sent:* Monday, August 19, 2013 8:38 PM
*To:* 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
− and non HTML character methods. The following html character
variations we have tested include:

1. -
2. —
3. −
4. −
5. —

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.