WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: WCAG and role="presentation"

for

From: Birkir R. Gunnarsson
Date: Aug 23, 2017 10:08AM


I agree with Sailesh in that it is highly dependent on the situation
whether not using the presentation role creates a WCAG 1.3.1 issue.
E.g. if a table can be determined by assistive technologies to be a
layout table (no summary attribute, no caption, no th cells, no cells
with scope) the presentation role is technically redundant.

But if a table uses any of the aforementioned techniques but is coded
for visual layout rather than to present tabular information, not
using the presentation role is a WCAG 1.3.1 violation (as explicitly
mentioned in WCAG Failure technique f43),
http://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/F43

For instance, a table is sometimes perceived to be sufficient to
associate form field labels with form fields (by coding the label as a
header cell).
This is obviously not true (to us who do accessibility fulltime).

We can fix the label association part of it without destroying the
table markup or we can remap the entire table as a group or a form
through ARIA, but regardless of the approach we use, a data table
should not be used to mark up a form.

Incidentally, Sailesh himself wrote one of my favorite articles on
accessible formfield labeling
http://mars.dequecloud.com/demo/form-markup.htm

In most cases using a data structure for layout presents no more than
an annoyance to an assistive technology user, so it is not a high
priority issue (although we can usually wield WCAG failure technique
F43 if needed).
The presentation role provides a quick and easy solution to address
that situation, and there is no reason why it shouldn't be used (if
used responsibly).

But there is always a chance that the use of semantic elements for
layout hides a more fundamental issue or misunderstanding that we have
to be mindful of.



On 8/23/17, Sailesh Panchang < <EMAIL REMOVED> > wrote:
> Yes but that's a validation issue not within the scope of SC 4.1.1 ...
> just like using scope attribute on a TD. Not good practice from HTML5
> code quality point of view.
> Thanks,
>
> On 8/23/17, Steve Faulkner < <EMAIL REMOVED> > wrote:
>> Note: It is a HTML5 conformance error
>>
>> If a table is to be used for layout it must be marked with the attribute
>>> role="presentation" for a user agent to properly represent the table to
>>> an assistive technology and to properly convey the intent of the author
>>> to
>>> tools that wish to extract tabular data from the document.
>>>
>> http://w3c.github.io/html/tabular-data.html#the-table-element
>>
>>
>>
>>
>> --
>>
>> Regards
>>
>> SteveF
>> Current Standards Work @W3C
>> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
>>
>> On 23 August 2017 at 15:37, Sailesh Panchang < <EMAIL REMOVED> >
>> wrote:
>>
>>> This does not fail WCAG 2.0 as others before me point out. I term it
>>> as a best practice that enhance user experience for SR users. This was
>>> one of the examples in my CSUN 2016 presentation that attempted to
>>> define the term accessibility best practices.
>>> Best wishes,
>>>
>>> On 8/23/17, Jonathan Avila < <EMAIL REMOVED> > wrote:
>>> >> Let's also keep in mind that using role="presentation" is easy.
>>> >
>>> > While I think we'd all agree that it is best to use role presentation
>>> > --
>>> the
>>> > question is whether it is a violation of WCAG. If table markup is not
>>> used
>>> > with TH, scope or other header association markup then the table is not
>>> > identifying header cells and it can be programmatically determined that
>>> the
>>> > table is a layout table. Since WCAG 2 was written without relying on
>>> ARIA
>>> > and was written before the ARIA spec was finalized -- the supporting
>>> > document seem to indicate that it's not a failure of WCAG as long as
>>> > not
>>> > using role presentation is accessibility supported. However we don't
>>> have
>>> > specific guidance on this and others are likely to disagree.
>>> >
>>> > Ideally these are the types of things that need to be clearly defined
>>> > in
>>> > supporting documents so we can achieve consistency with testing tools
>>> > and
>>> > with conformance evaluations. Questions such as this can be raised
>>> > with
>>> > the Accessibility Guidelines Working Group on Github
>>> > (https://github.com/w3c/wcag/issues). If you feel strongly about
>>> something
>>> > it might be helpful to put together a suggested failure technique --
>>> > although getting failure techniques accepted has been proven difficult.
>>> >
>>> > Jonathan
>>> >
>>> > Jonathan Avila
>>> > Chief Accessibility Officer
>>> > Level Access, inc. (formerly SSB BART Group, inc.)
>>> > (703) 637-8957
>>> > <EMAIL REMOVED>
>>> > Visit us online: Website | Twitter | Facebook | LinkedIn | Blog
>>> > Looking to boost your accessibility knowledge? Check out our free
>>> webinars!
>>> >
>>> > The information contained in this transmission may be attorney
>>> > privileged
>>> > and/or confidential information intended for the use of the individual
>>> > or
>>> > entity named above. If the reader of this message is not the intended
>>> > recipient, you are hereby notified that any use, dissemination,
>>> distribution
>>> > or copying of this communication is strictly prohibited.
>>> >
>>> >