E-mail List Archives
Thread: Financial Tables
Number of posts in this thread: 3 (In chronological order)
From: Julie Lewis
Date: Thu, Oct 15 2015 12:39PM
Subject: Financial Tables
No previous message | Next message →
Great points all. Thank you.
Don - the table isn't set up that way.
The units are specific to the columns. The left has the revenue source,
the next few columns are the amounts in US dollars by year. So the column
header is "year" not "amount". And the right-most column is "percent
change". That one is self-explanatory.
By default, the screen reader will just read the numbers from left to
right - which is pretty meaningless.
If they are reading by column, then "percent change" is self-explanatory,
but "year" isn't. A single dollar sign in the first row might help. But
is that enough?
To make things even more complicated, there are multiple tables and some
are in thousands of dollars and some are in millions of dollars.
We have literally thousands of tables of our web site, so we need to trade
off what's reasonable from a development standpoint with what is needed
for accessibility (and usability) for all users.
In some cases I can get away with tweaking the table format, but in many
others I can't do that. The people creating the tables have been
formatting them in very specific ways for many years, so I need to be able
to justify those changes. (They get ruffled if I don't use double
underlines and leave extra space before a total.)
The secondary problem of putting negative numbers in parentheses wouldn't
be a problem if the screen readers read the parentheses, but it doesn't
sound like they do that consistently.
Regards,
Julie Lewis
On 10/15/15, 1:00 PM, "WebAIM-Forum on behalf of
= EMAIL ADDRESS REMOVED = "
< = EMAIL ADDRESS REMOVED = on behalf of
= EMAIL ADDRESS REMOVED = > wrote:
>On 10/15/15, _mallory < = EMAIL ADDRESS REMOVED = > wrote:
>>It also can't hurt to state, before the table (or maybe after, but
>>better before) how you denote negatives, or if the dollars are in
>>millions (or that it's in dollars at all)... There was a time when I
>>did not know of the (parentheses) convention for negative numbers, and
>>only learned of it when I was old enough to do taxes. So it doesn't
>>hurt to tell people in a quick short sentence stuff that might be
>>obvious or well-known to the majority of readers anyway.
>>
>>If someone knows or suspects their AT won't read out a symbol, knowing
>>beforehand that a symbol is being used can let people decide if they
>>need to fiddle with their punctuation first. In any case, can't hurt
>>to say it.
>>
>>This can give you more freedom inside the table itself.
>>
>>_mallory
>>
>>On Tue, Oct 13, 2015 at 02:29:03PM -0700, Don Mauck wrote:
>>>From my understanding of this thread, it seems to me that each "row"
>>>should have the math sign relevant to that row. I am however, only
>>>thinking from a screen readers perspective and realize that there are
>>>other contributing factors. What I'm not clear on, is if the intent
>>>is that each row could have a different math sign and that there will
>>>be columns of data related to a column heading.
>>>
>>>-----Original Message-----
>>>From: Julie Lewis [mailto: = EMAIL ADDRESS REMOVED = ]
>>>Sent: Tuesday, October 13, 2015 12:55 PM
>>>To: = EMAIL ADDRESS REMOVED =
>>>Subject: Re: [WebAIM] Accessibility in Financial Tables in HTML
>>>
>>>Sorry if I don¹t do this right it¹s been a looong time since I
>>>participated in an email only list-serv.
>>>
>>>I wrote:
>>>> The printed version of the table has dollar signs in front of the
>>>>numbers on the first and last rows and percent signs only on the
>>>>first and last rows. Does that provide enough context? Or should
>>>>every cell have $ or % explicitly called out?
>>>
>>>Olaf said:
>>>Å this does not have anything to do with accessibility, but with
>>>usability
>>>
>>>I reply:
>>>
>>>I disagree. From a usability perspective it¹s pretty clear that less
>>>is more. The question is whether a non-sighted user will have enough
>>>context to figure out what the numbers mean if they are just traversing
>>>the table.
>>>
>>>The header for percent change is self-explanatory, but the headers
>>>for the dollar amounts aren¹t unless the user actually listens to the
>>>title.
>>>
>>>Since HTML5 has deprecated the table summary tag, (why oh why did
>>>they do
>>>that?) that may not be an option going forward.
>>>
>>>It¹s a bummer that MacOS doesn¹t read the parentheses, since that¹s a
>>>much cleaner way of representing negatives than relying on a dash.
>>>
>>>Regards,
>>>Rio
>>>
>>>>>>>>>archives at http://webaim.org/discussion/archives
>>>>>>>>>>>>archives at http://webaim.org/discussion/archives
>>>>>>>>>archives at http://webaim.org/discussion/archives
>>>>
>>>athttp://webaim.org/discussion/archives
>>
>
>
From: Cliff Tyllick
Date: Sat, Oct 17 2015 3:14AM
Subject: Re: Accessibility in Financial Tables in HTML
← Previous message | Next message →
Although I agree with the points Bevi makesâalbeit less enthusiastically about litigation as a way to move the AT forward (File defects first. Unlike many other products, for AT each of us can participate in the QC review.)âI also agree wholeheartedly with Mallory.
To add a note before a table to indicate that negative values are in parentheses helps many people and hurts no one.
Cliff Tyllick
Texas Department of Assistive and Rehabilitative Services
Sent from my iPhone
Although its spellcheck often saves me, all goofs in sent messages are its fault.
> On Oct 15, 2015, at 12:52 PM, Chagnon | PubCom.com < = EMAIL ADDRESS REMOVED = > wrote:
>
> Sailesh wrote:
> "So does it become the developer's responsibility then?"
>
> Yes and no.
>
> There are 3 stakeholders in accessibility:
>
> 1) Those who create and publish the content, regardless of the media, distribution method, file format, etc.
>
> 2) Those who read, access, and use the content.
>
> 3) The technology manufacturers that make the products used by people to read the content. That includes all of the AT manufacturers, as well as browser manufacturers, office software, Adobe Acrobat and its knockoffs, operating systems, etc.
>
> All 3 stakeholders must do their part of accessibility.
>
> As a content creator and publisher, the only part I can do is use plain language for all users, code it correctly for accessibility, visually design it for sighted users, and distribute it in formats that are accessible.
>
> In our example from this thread, I make sure I use Unicode character 2212 for the negative numbers in my tables because of all the methods to denote a negative number, it is the most accurate way across all languages, industries, and technologies, and doesn't have multiple meanings like parentheses ( ) and the color red.
>
> It's the job of stakeholders #2, the users, to understand what that symbol means and to set their AT to interpret it correctly.
>
> It's the job of stakeholders #3, the technology manufacturers, to recognize, voice, and display the character in their technology.
>
> And all 3 stakeholders do this according to the standards of WCAG, PDF/UA, etc. (who aren't stakeholders but instead are the "benevolent dictators" of this process).
>
> If any of these stakeholders doesn't do their job, then we all fail. Personally, I think it would help greatly if someone would start citing/suing stakeholders #3. Too many of our AT don't recognize Unicode 2212 as the negative sign and either ignore it or voice it as an unknown character. It's 2015 and we've had Unicode since, what, the 1970s?
>
> And then go on and cite/sue content creators who use the hyphen instead of the minus character for negative numbers. Or who mis-use an en-dash. And an em-dash, too. These are not new-fangled glyphs: been using them for decades since I was a typesetter and editor, and they are part of standard English grammar and punctuation. Part of this is a holdover from antique QWERTY typewriter keyboards. I have typewriters that don't have the numeral 1 and instead you use a lowercase l for that number. How accessible is that!
>
> Sailesh wrote: "... Where does it stand in priority when there are more hard core pressing accessibility issues for content authors to tackle?"
>
> Anyone can make an argument that every facet is just as important as the other. But that's what management/workflow specialists like myself evaluate, triage, and then create a deployment plan.
>
> In my mind, misreading negative numbers as positive is a huge failure because it conveys the wrong information to SR users. Maybe a lawsuit based on loss of money, time, or even life/health, might prod this issue to the top of the stack.
>
> --Bevi Chagnon
>
> â â â
> Bevi Chagnon | www.PubCom.com | = EMAIL ADDRESS REMOVED =
> Technologists, Consultants, Trainers, Designers, and Developers
> for publishing & communication
> | PRINT | WEB | PDF | EPUB | Sec. 508 ACCESSIBILITY |
> â â â
>
> > > >
From: Cliff Tyllick
Date: Sat, Oct 17 2015 3:29AM
Subject: Re: Financial Tables
← Previous message | No next message
Julie, thanks for the greater detail. With so much going on, the simplest approach for accessibility as well as usability would be to add this additional information in a note before the table: "Revenue stated in billion USD. Negative values are in parentheses."
The extra space before and double underline beneath (or is it above?) the totals seem like features that should be added by CSS, using a class for the role in question. For these visible affordances, no explanatory note is necessary.
Cliff Tyllick
Texas Department of Assistive and Rehabilitative Services
Sent from my iPhone
Although its spellcheck often saves me, all goofs in sent messages are its fault.
> On Oct 15, 2015, at 1:39 PM, Julie Lewis < = EMAIL ADDRESS REMOVED = > wrote:
>
> Great points all. Thank you.
>
> Don - the table isn't set up that way.
>
> The units are specific to the columns. The left has the revenue source,
> the next few columns are the amounts in US dollars by year. So the column
> header is "year" not "amount". And the right-most column is "percent
> change". That one is self-explanatory.
>
> By default, the screen reader will just read the numbers from left to
> right - which is pretty meaningless.
> If they are reading by column, then "percent change" is self-explanatory,
> but "year" isn't. A single dollar sign in the first row might help. But
> is that enough?
>
> To make things even more complicated, there are multiple tables and some
> are in thousands of dollars and some are in millions of dollars.
>
> We have literally thousands of tables of our web site, so we need to trade
> off what's reasonable from a development standpoint with what is needed
> for accessibility (and usability) for all users.
>
> In some cases I can get away with tweaking the table format, but in many
> others I can't do that. The people creating the tables have been
> formatting them in very specific ways for many years, so I need to be able
> to justify those changes. (They get ruffled if I don't use double
> underlines and leave extra space before a total.)
>
> The secondary problem of putting negative numbers in parentheses wouldn't
> be a problem if the screen readers read the parentheses, but it doesn't
> sound like they do that consistently.
>
> Regards,
> Julie Lewis
>
>
>
>
> On 10/15/15, 1:00 PM, "WebAIM-Forum on behalf of
> = EMAIL ADDRESS REMOVED = "
> < = EMAIL ADDRESS REMOVED = on behalf of
> = EMAIL ADDRESS REMOVED = > wrote:
>
>>> On 10/15/15, _mallory < = EMAIL ADDRESS REMOVED = > wrote:
>>> It also can't hurt to state, before the table (or maybe after, but
>>> better before) how you denote negatives, or if the dollars are in
>>> millions (or that it's in dollars at all)... There was a time when I
>>> did not know of the (parentheses) convention for negative numbers, and
>>> only learned of it when I was old enough to do taxes. So it doesn't
>>> hurt to tell people in a quick short sentence stuff that might be
>>> obvious or well-known to the majority of readers anyway.
>>>
>>> If someone knows or suspects their AT won't read out a symbol, knowing
>>> beforehand that a symbol is being used can let people decide if they
>>> need to fiddle with their punctuation first. In any case, can't hurt
>>> to say it.
>>>
>>> This can give you more freedom inside the table itself.
>>>
>>> _mallory
>>>
>>>> On Tue, Oct 13, 2015 at 02:29:03PM -0700, Don Mauck wrote:
>>>> From my understanding of this thread, it seems to me that each "row"
>>>> should have the math sign relevant to that row. I am however, only
>>>> thinking from a screen readers perspective and realize that there are
>>>> other contributing factors. What I'm not clear on, is if the intent
>>>> is that each row could have a different math sign and that there will
>>>> be columns of data related to a column heading.
>>>>
>>>> -----Original Message-----
>>>> From: Julie Lewis [mailto: = EMAIL ADDRESS REMOVED = ]
>>>> Sent: Tuesday, October 13, 2015 12:55 PM
>>>> To: = EMAIL ADDRESS REMOVED =
>>>> Subject: Re: [WebAIM] Accessibility in Financial Tables in HTML
>>>>
>>>> Sorry if I don¹t do this right it¹s been a looong time since I
>>>> participated in an email only list-serv.
>>>>
>>>> I wrote:
>>>>> The printed version of the table has dollar signs in front of the
>>>>> numbers on the first and last rows and percent signs only on the
>>>>> first and last rows. Does that provide enough context? Or should
>>>>> every cell have $ or % explicitly called out?
>>>>
>>>> Olaf said:
>>>> Å this does not have anything to do with accessibility, but with
>>>> usability
>>>>
>>>> I reply:
>>>>
>>>> I disagree. From a usability perspective it¹s pretty clear that less
>>>> is more. The question is whether a non-sighted user will have enough
>>>> context to figure out what the numbers mean if they are just traversing
>>>> the table.
>>>>
>>>> The header for percent change is self-explanatory, but the headers
>>>> for the dollar amounts aren¹t unless the user actually listens to the
>>>> title.
>>>>
>>>> Since HTML5 has deprecated the table summary tag, (why oh why did
>>>> they do
>>>> that?) that may not be an option going forward.
>>>>
>>>> It¹s a bummer that MacOS doesn¹t read the parentheses, since that¹s a
>>>> much cleaner way of representing negatives than relying on a dash.
>>>>
>>>> Regards,
>>>> Rio
>>>>
>>>> >>>> >>>> archives at http://webaim.org/discussion/archives
>>>> >>>> >>>> >>>> archives at http://webaim.org/discussion/archives
>>>> >>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >> >> >> athttp://webaim.org/discussion/archives
>> >
> > > >