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.