WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Presenting tabular data in visually non-tabular ways

for

From: Sailesh Panchang
Date: Mar 6, 2015 7:35AM

I have always suggested use of 2-column data tables with column
header cells (if present) and row header cells marked up as TH for
name->value pairs .
This is important when one can visually discern the semantic
relationship between data cells.
A screen reader user might wish to go down the first column and simply
review the attributes and not be concerned with the values for the
moment.
Or,it is easy to go down the list of attributes to a particular one
and then check its value.
Or, one can move down col#2 using table navigation and have the label
automatically announced by the SR.
Consider a case where the same set of attributes is repeated for
different subjects (farms / accounts / student etc.) on the page and
the UI design requires a 2-column representation for everysubject.

Failure to mark up row header cells as TH or with scope=row) (or other
method) is a violation as the semantic relation is not
programmatically determinable or _available in text_.
Using dl-dt-dd is alright but if not my first recommendation.
Some believe there are more critical issues that need to be addressed
and this one is not high on the priority. I completely discount this
reasoning.
Thanks,
Sailesh


On 3/5/15, Cliff Tyllick < <EMAIL REMOVED> > wrote:
> Steve, I agree with Birker that structure needs to be coded into the
> content.
>
> Heading and list elements could be used to create that structure, but in the
> content I see so many instances of repeated words that it screams for a
> table.
>
> I can imagine that the presentation without a table would be appropriate
> when an individual set of results is presented. Still, it would need markup
> as a list—perhaps as a definition list—at the very least. In visually
> skimming the list, I perceive semantic relationships. Those relationships
> must also be perceivable to people who cannot see.
>
> 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 Mar 5, 2015, at 11:14 AM, Birkir R. Gunnarsson
>> < <EMAIL REMOVED> > wrote:
>>
>> If a table is the most semantically appropriate element for data, that
>> data should be set up as a table, not doing so would be a violation of
>> WCAG 1.3.1
>> If it looks like a table, is presented as a table and has visual
>> characteristics of a table with at least well-defined column headers,
>> that needs to be set up as a table with all required markup (marking
>> up column header cells and, if appropriate, rowheader cells).
>> If the faux table only has two columns and makes sense when linearized
>> I would not call this out, but when you have more than two columns,
>> tables do not linearize well and relevant information is easily lost
>> to users of screen readers if the datastructure markup is missing.
>> ARIA can be used to fix problems such as missing row or column headers
>> and, in extreme cases, can even be applied to existing containers to
>> create a grid from scratch, though that is quite frankly a bit silly.
>> So, yes, I would absolutely call those patterns out under WCAG 1.3.1
>> Cheers
>>
>>
>> On 3/5/15, Meacham, Steve - FSA, Kansas City, MO
>> < <EMAIL REMOVED> > wrote:
>>> I'm seeing this pattern more and more often: rows of data presented that
>>> could/should/would have traditionally been in a table with well-defined
>>> columns, but now presented as more of a blob of text. For example:
>>>
>>> Assigned
>>> Due 3/1/2015
>>>
>>> Farm #12345 - 2,500 Acres
>>> Montgomery County, Michigan
>>> Approver: Jonathan McCormick
>>>
>>> Started
>>> Due 5/10/2015
>>>
>>> Farm #2345 - 1,200 Acres
>>> Montgomery County, Michigan
>>> Approver: Jonathan McCormick
>>>
>>> Competed
>>> Due 5/15/2015
>>>
>>> Farm #45689 - 450 Acres
>>> Montgomery County, Michigan
>>> Approver: Randy Smith
>>>
>>> Approved
>>> Due 6/1/2015
>>>
>>> Farm #3214 - 12,450 Acres
>>> Montgomery County, Michigan
>>> Approver: Julia Bartosky
>>>
>>>
>>> Visually, this actually seems to work. If you were trying to pick
>>> something
>>> from a list of items, all the necessary distinctives are there,
>>> positioned
>>> consistently to allow quickly scanning through the rows with our eyes.
>>> There are even in-line labels for non-self-evident data elements.
>>>
>>> I don't believe that this works so well for users of AT, such as
>>> single-line
>>> refreshable Braille, or screen readers. How can such a user 'scan' the
>>> information, looking at one column-equivalent of data (Approver, for
>>> example, in the example above)?
>>>
>>> What is our response, as both UX and Accesibility professionals?
>>>
>>> Steve Meacham
>>> FSA Section 508 Coordinator
>>> Office: +1 (816) 926-1942
>>> Call or Text: +1 (202) 455-USDA (8732)
>>>
>>>
>>>
>>>
>>>
>>> This electronic message contains information generated by the USDA solely
>>> for the intended recipients. Any unauthorized interception of this
>>> message
>>> or the use or disclosure of the information it contains may violate the
>>> law
>>> and subject the violator to civil or criminal penalties. If you believe
>>> you
>>> have received this message in error, please notify the sender and delete
>>> the
>>> email immediately.
>>> >>> >>> >>
>>
>> --
>> Work hard. Have fun. Make history.
>> >> >> > > > >