E-mail List Archives
Thread: WCAG and role="presentation"
Number of posts in this thread: 13 (In chronological order)
From: Peter Shikli
Date: Tue, Aug 22 2017 3:32PM
Subject: WCAG and role="presentation"
No previous message | Next message →
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 ADDRESS 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
From: Detlev Fischer
Date: Wed, Aug 23 2017 3:00AM
Subject: Re: WCAG and role="presentation"
← Previous message | Next message →
In the absence of WCAG Common Failure, I would say no. While layout tables without role=presentation are a familiar nuisance for screen reader users, it seems excessive to fail a page for not using that role. Note that F92 covers the opposite: data table markup hidden from screen readers by using role=presentation. This is clearly a much more significant issue.
Having said that, screen reader users may think differently. If consensus is that listening to table mareke-up is more than a slight nuisance,there would cetainly be an opportunity to create new failure since this seems easily testable.
Detlev
--
Peter Shikli schrieb am 22.08.2017 23:32:
> 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 ADDRESS 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
>
>
> > > > >
From: Srinivasu Chakravarthula
Date: Wed, Aug 23 2017 3:07AM
Subject: Re: WCAG and role="presentation"
← Previous message | Next message →
+1. Also, WCAG does not define a specific method to achieve a purpose.
Regards,
Srinivasu Chakravarthula - Twitter: http://twitter.com/CSrinivasu/
Website: http://www.srinivasu.org | http://serveominclusion.com
Let's create an inclusive web!
Lead Accessibility Consultant, Informatica
On Wed, Aug 23, 2017 at 2:30 PM, Detlev Fischer < = EMAIL ADDRESS REMOVED =
> wrote:
> In the absence of WCAG Common Failure, I would say no. While layout tables
> without role=presentation are a familiar nuisance for screen reader users,
> it seems excessive to fail a page for not using that role. Note that F92
> covers the opposite: data table markup hidden from screen readers by using
> role=presentation. This is clearly a much more significant issue.
>
> Having said that, screen reader users may think differently. If consensus
> is that listening to table mareke-up is more than a slight nuisance,there
> would cetainly be an opportunity to create new failure since this seems
> easily testable.
>
> Detlev
>
> --
>
> Peter Shikli schrieb am 22.08.2017 23:32:
>
> > 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 ADDRESS 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
> >
> >
> > > > > > > > > >
>
> > > > >
From: Lovely, Brian (CONT)
Date: Wed, Aug 23 2017 6:54AM
Subject: Re: WCAG and role="presentation"
← Previous message | Next message →
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.
From: Birkir R. Gunnarsson
Date: Wed, Aug 23 2017 7:28AM
Subject: Re: WCAG and role="presentation"
← Previous message | Next message →
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 ADDRESS 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.
>
>
From: Jonathan Avila
Date: Wed, Aug 23 2017 8:25AM
Subject: Re: WCAG and role="presentation"
← Previous message | Next message →
> 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 ADDRESS 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.
From: Sailesh Panchang
Date: Wed, Aug 23 2017 8:37AM
Subject: Re: WCAG and role="presentation"
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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.
>
>
From: Steve Faulkner
Date: Wed, Aug 23 2017 9:07AM
Subject: Re: WCAG and role="presentation"
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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 ADDRESS 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.
> >
> >
From: Sailesh Panchang
Date: Wed, Aug 23 2017 9:35AM
Subject: Re: WCAG and role="presentation"
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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.
>> >
>> >
From: Birkir R. Gunnarsson
Date: Wed, Aug 23 2017 10:08AM
Subject: Re: WCAG and role="presentation"
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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.
>>> >
>>> >
From: Mark Rogers
Date: Thu, Aug 24 2017 1:09AM
Subject: Re: WCAG and role="presentation"
← Previous message | Next message →
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 ADDRESS 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 ADDRESS REMOVED = on behalf of = EMAIL ADDRESS 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 ADDRESS 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.
From: Steve Faulkner
Date: Thu, Aug 24 2017 1:16AM
Subject: Re: WCAG and role="presentation"
← Previous message | Next message →
>
> 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = on behalf of
> = EMAIL ADDRESS 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 ADDRESS 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.
>
>
From: Mark Rogers
Date: Thu, Aug 24 2017 1:59AM
Subject: Re: WCAG and role="presentation"
← Previous message | No next message
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 ADDRESS 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 ADDRESS REMOVED = on behalf of = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = on behalf of
> = EMAIL ADDRESS 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 ADDRESS 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.
>
>