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 9:33AM

A glossary of terms is a definition list.
The term in the first row is unrelated to the term in the next.
On the other hand:
Street address, Home type (single / townhome), lot size, Sq ft size,
Year built, etc. are all attributes for a home.
Now one can represent this data in a 2-col tabular layout for
different homes one below the other. This will suit a page with such
data for a single home too.
A data table is better than a DL, no?
Note, often the label in the 1st col is styled distinctly and there
may or may not be grid lines. In a glossary there are never any grid
lines.
Thanks,
Sailesh


On 3/6/15, Jonathan C Cohn < <EMAIL REMOVED> > wrote:
> 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
>
>
>
> > > >