RE: screen reader reporting of negative values

I agree with John that we need to go beyond "letter of the law'
accessibility, which is why I raised the question. I don't think we can
assume all screen reader users are comfortable changing the verbosity
settings - I have met many who just use their technology as it comes "out of
the box".

My main concern was with financial statements where the implications of not
noticing the difference between a minus and plus value could be enormous.
While I have heard of a few people not noticing the minus symbol (dash) in a
test environment, I guess in the real  world with your own bank account most
people are likely to be a little more careful. 

>From the discussions, it seems that the standard keyboard dash maybe the
best way to go, but I am still attracted to the idea of adding the word
minus (off left) and I don't see how this would cause as real problems for
Braille users.

While not exactly the same, for developers who just use the keyboard star to
indicate required form fields I suggest they also use aria-required, because
some screen readers don't report the star by default. (I should add my
preferred method however is just the word "required", but most designers are
not happy with this.)

Roger

-----Original Message-----
From: Foliot, John [mailto:john.foliot@chase.com] 
Sent: Tuesday, 20 August 2013 5:45 AM
To: Jennifer Sutton; 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 — and — 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 Monday, 19 August 2013 21:41:30 UTC