WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Presenting tabular data in visually non-tabular ways

for

From: Jonathan C Cohn
Date: Mar 6, 2015 8:32AM

How would you distinguish a two column output from a definition It sounds to me like the functionality of what you are describing is actually a definition list.

Thanks,
> On Mar 6, 2015, at 09:35, Sailesh Panchang < <EMAIL REMOVED> > wrote:
>
> 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.
>>> >>> >>> >> >> >> >>
> > > Best wishes,

Jonathan