WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: WCAG and role="presentation"

for

From: Mark Rogers
Date: Aug 24, 2017 1:59AM


Given that heuristics can't reliably programmatically determine whether a table without role=presentation or TH is a layout table or data table, there's an argument for saying this fails:

'1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text-

Worth noting some types of tabular data don't have natural headers (Soduko grids for example) but role=table would be useful here for forcing these to be read as a table.

Best Regards
Mark

--
Mark Rogers - <EMAIL REMOVED>
PowerMapper Software Ltd - www.powermapper.com
Registered in Scotland No 362274 Quartermile 2 Edinburgh EH3 9GL



On 24/08/2017, 08:16, "WebAIM-Forum on behalf of Steve Faulkner" < <EMAIL REMOVED> on behalf of <EMAIL REMOVED> > wrote:

>
> Basically without role=presentation or TH you have Schrödinger's layout
> table - it will be voiced as layout or data depending on a combination of
> screen reader, browser, window size and default font size.


Which is why role=presentation is a MUST conformance requirement in HTML5
as it is the only standardised method of suppressing incorrect table
semantics.

It is never a good idea to rely on screen reader heuristics.

--

Regards

SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;

On 24 August 2017 at 08:09, Mark Rogers < <EMAIL REMOVED> > wrote:

> Without role=presentation or TH screen readers use heuristics to decide if
> a table is layout or data. The heuristics vary greatly between screen
> readers, so a table can be voiced as layout in one screen reader, but data
> in another.
>
> Data used by heuristics includes: number of rows, style of cell borders
> and row background, presence of form controls, embedded objects and nested
> tables. NVDA uses different heuristics if it's running with IE (where it
> uses NVDA's own heuristics) and Firefox (where it uses Firefox's
> layout-guess heuristic).
>
> JAWS 16 and earlier (and possibly recent versions) decide that a table
> with more than 2 cells and more than 2 rows with 4 cells between 200 and
> 16,000 square pixels is a data table. This is affected by factors unrelated
> to the table data such as browser window size and default browser font
> size. It also produces different results on IE (where it includes cell
> padding in size calculation) and Firefox (excludes cell padding from size
> calculation). If you have a table with width0% you can flip it between
> layout and data just by resizing the window.
>
> Basically without role=presentation or TH you have Schrödinger's layout
> table - it will be voiced as layout or data depending on a combination of
> screen reader, browser, window size and default font size.
>
> Best Regards
> Mark
>
> --
> Mark Rogers - <EMAIL REMOVED>
> PowerMapper Software Ltd - www.powermapper.com
> Registered in Scotland No 362274 Quartermile 2 Edinburgh EH3 9GL
>
>
>
> On 23/08/2017, 15:25, "WebAIM-Forum on behalf of Jonathan Avila" <
> <EMAIL REMOVED> on behalf of
> <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.
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> Behalf Of Birkir R. Gunnarsson
> Sent: Wednesday, August 23, 2017 9:28 AM
> To: Lovely, Brian (CONT) < <EMAIL REMOVED> >; WebAIM
> Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] WCAG and role="presentation"
>
> Well put Brian.
> Let's also keep in mind that using role="presentation" is easy.
> You add this attribute where appropriate. It does not trigger
> additional functionality testing(except with a screen reader) and it does
> not change the webpage appearance so you don't have to get designers
> involved.
>
> And if you are consistently using a semantic element to achieve a
> certain appearance (or for other non semantic purposes), you really should
> take a look at the design in general (if you have that luxury) to figure
> out why. It may have other consequences, or break after user agent updates.
>
>
>
> On 8/23/17, Lovely, Brian (CONT) via WebAIM-Forum <
> <EMAIL REMOVED> > wrote:
> > I would call out a page for a table containing non-tabular data.
> >
> > The role of presentation strips an element of its semantic meaning
> > (essentially converting it to the equivalent of a non-semantic
> > container like a div or span). The semantic meaning of elements is
> an
> > important part of accessibility, particularly actionable elements.
> Use
> > of the correct semantic element provides information about the type
> of
> > information presented, and how the element can be successfully
> > interacted with. I'm not always a "slippery slope" kind of guy, but
> > once you start to erode the trust in the semantic information you
> > present, the user really doesn't know what to expect and must take
> the
> > extra time and energy to determine if elements are actually what they
> > are presenting themselves to be, and if those elements actually
> behave as expected.
> >
> > -----Original Message-----
> > From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> > Behalf Of Peter Shikli
> > Sent: Tuesday, August 22, 2017 5:33 PM
> > To: WebAIM Forum < <EMAIL REMOVED> >
> > Subject: [WebAIM] WCAG and role="presentation"
> >
> > My question is whether it is a violation to not use
> > role="presentation" on elements which are used for presentation
> > purposes only, such as tables. I realize we should use it for
> > decorative tables, but is it a requirement for a Level AA rating per
> > WCAG Success Guideline 1.3.1 "Info and Relationships"?
> >
> > Understanding WCAG 2.0, http://www.w3.org/TR/UNDERSTANDING-WCAG20/
> > states that when possible, information presented visually should also
> > be made available programmatically. Many examples are given, but I
> > would like some clarification specifically on the use of WAI-ARIA's
> role="presentation."
> >
> > Sincerely,
> > Peter Shikli
> > <EMAIL REMOVED>
> > 503-570-6831
> > FAX: 213-337-7029
> > Access2online
> > 29030 SW Town Center Loop East
> > Suite 202-187
> > Wilsonville, OR 97070
> > www.Access2online.com
> > Prison inmates helping websites become accessible
> >
> >
> > > > > > archives at http://webaim.org/discussion/archives
> > > > > >
> > The information contained in this e-mail is confidential and/or
> > proprietary to Capital One and/or its affiliates and may only be used
> > solely in performance of work or services for Capital One. The
> > information transmitted herewith is intended only for use by the
> > individual or entity to which it is addressed. If the reader of this
> > message is not the intended recipient, you are hereby notified that
> > any review, retransmission, dissemination, distribution, copying or
> > other use of, or taking of any action in reliance upon this
> > information is strictly prohibited. If you have received this
> > communication in error, please contact the sender and delete the
> material from your computer.
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > archives at http://webaim.org/discussion/archives
> > > > > >
>
> > > > >