WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Presenting tabular data in visually non-tabular ways

for

From: Cliff Tyllick
Date: Mar 5, 2015 8:35PM

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.
> > >