E-mail List Archives
Thread: Landmarks
Number of posts in this thread: 11 (In chronological order)
From: Isabel Holdsworth
Date: Thu, May 02 2019 3:23AM
Subject: Landmarks
No previous message | Next message →
Hi all,
I'm currently auditing a web application that uses ARIA landmarks in a
very random fashion.
I've discovered that using landmarks within a dialog causes JAWS 2018
to say nothing but "dialog" when trying to interact with elements
using the virtual cursor and sometimes the Tab key. So I'll recommend
they stop doing this.
On some pages they have a <div role="main"> wrapper around unique page
content, but they're not using header or footer roles. Is it OK to
have some content wrapped in landmarks and the rest not? I know that
ideally if landmarks are to be used at all they should be applied to
the whole page, but would not doing so constitute a WCAG 2.0
violation?
I've found a few banner landmarks inside main landmarks - do you think
this would be a fail? If so under which guideline? 1.3.1 perhaps?
Thanks as always, Isabel
From: Steve Green
Date: Thu, May 02 2019 3:53AM
Subject: Re: Landmarks
← Previous message | Next message →
My view is that it is a violation of 1.3.1 if landmarks are not used or are used incorrectly. In most cases I would expect all page content to be in at least one landmark - there may be exceptions where that is not appropriate but I can't think of any.
Steve Green
Managing Director
Test Partners Ltd
From: Birkir R. Gunnarsson
Date: Thu, May 02 2019 4:23AM
Subject: Re: Landmarks
← Previous message | Next message →
You could pin it un 1.3.1 or 4.1.1 (ARIA is not being used according
to spec, so it feels like 4.1.1 is a valid argument).
I push for people using the big 3 correctly, header/main/footer
(banner/main/contentinfo) but usually stop there, because in my
usability testing I didn't see anyone use landmarks and too many
landmarks on a page quickly render them pretty useless.
Your plague of banner landmarks is probably caused by use of the
<header> element (it maps to the banner role if it is a child of the
<body> element and should only be used in connection with <article> or
<section> elements if not used for the webpage header).
Jaws is overly generous when it comes to mapping the <header> element
to a banner landmark.
On 5/2/19, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:
> My view is that it is a violation of 1.3.1 if landmarks are not used or are
> used incorrectly. In most cases I would expect all page content to be in at
> least one landmark - there may be exceptions where that is not appropriate
> but I can't think of any.
>
> Steve Green
> Managing Director
> Test Partners Ltd
>
>
>
From: Mallory
Date: Thu, May 02 2019 5:53AM
Subject: Re: Landmarks
← Previous message | Next message →
On Thu, May 2, 2019, at 12:23 PM, Birkir R. Gunnarsson wrote:
...
> Jaws is overly generous when it comes to mapping the <header> element
> to a banner landmark.
IE as well. Thus the combination of JAWS and IE makes every header a banner.
cheers,
_mallory
From: Isabel Holdsworth
Date: Thu, May 02 2019 5:53AM
Subject: Re: Landmarks
← Previous message | Next message →
Thanks guys. It's actually a <div> with a banner role, sometimes
inside a <div> with a main role, sometimes randomly inside a dialog.
Sometimes they wrap it around heading tags.
These random banners are quite a clear-cut fail, but what about
instances where there's a <div role="main"> wrapper around the main
content, but the header, navs and footer don't have landmarks? Is this
a fail too?
I know this issue won't stop anyone from using the content, but we
have time to do a comprehensive audit, and the devs will probably have
time to fix most of the issues we find, so why not!
Cheers, Isabel
On 02/05/2019, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
> You could pin it un 1.3.1 or 4.1.1 (ARIA is not being used according
> to spec, so it feels like 4.1.1 is a valid argument).
> I push for people using the big 3 correctly, header/main/footer
> (banner/main/contentinfo) but usually stop there, because in my
> usability testing I didn't see anyone use landmarks and too many
> landmarks on a page quickly render them pretty useless.
> Your plague of banner landmarks is probably caused by use of the
> <header> element (it maps to the banner role if it is a child of the
> <body> element and should only be used in connection with <article> or
> <section> elements if not used for the webpage header).
> Jaws is overly generous when it comes to mapping the <header> element
> to a banner landmark.
>
>
> On 5/2/19, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:
>> My view is that it is a violation of 1.3.1 if landmarks are not used or
>> are
>> used incorrectly. In most cases I would expect all page content to be in
>> at
>> least one landmark - there may be exceptions where that is not
>> appropriate
>> but I can't think of any.
>>
>> Steve Green
>> Managing Director
>> Test Partners Ltd
>>
>>
>>
From: Jonathan Avila
Date: Thu, May 02 2019 7:45AM
Subject: Re: Landmarks
← Previous message | Next message →
> My view is that it is a violation of 1.3.1 if landmarks are not used or are used incorrectly. In most cases I would expect all page content to be in at least one landmark - there may be exceptions where that is not appropriate but I can't think of any.
Of note the Accessibility Guidelines working group has not created a documented failure for this because experts could not agree that a lack of landmarks was indeed a WCAG failure. Other elements such as headings or text could be used to communicate the visual page structure without requiring all pages to have landmarks. So it really depends on what is communicated visually through presentation and what other elements and text exist on the page.
Jonathan
From: Steve Green
Date: Thu, May 02 2019 7:59AM
Subject: Re: Landmarks
← Previous message | Next message →
The absence of landmarks is certainly not the most serious of accessibility barriers, but landmarks have the advantage that they convey both the start and end of sections of content, which headings do not.
Page headers and footers are usually conveyed visually in a totally unambiguous manner. SC 1.3.1 requires that this structure is conveyed programmatically, and landmarks are the best way to do that. In fact, how else would you do so? I struggle to see how this cannot be a non-compliance.
Steve
From: Isabel Holdsworth
Date: Thu, May 02 2019 8:25AM
Subject: Re: Landmarks
← Previous message | Next message →
I kind of feel like either use them correctly or not at all. Does this
seem a reasonable enough approach?
Steve, you make a very good point about landmarks denoting the end as
well as the start, which mechanisms such as H1 headings and skip links
can't do.
Cheers, Isabel
On 02/05/2019, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:
> The absence of landmarks is certainly not the most serious of accessibility
> barriers, but landmarks have the advantage that they convey both the start
> and end of sections of content, which headings do not.
>
> Page headers and footers are usually conveyed visually in a totally
> unambiguous manner. SC 1.3.1 requires that this structure is conveyed
> programmatically, and landmarks are the best way to do that. In fact, how
> else would you do so? I struggle to see how this cannot be a
> non-compliance.
>
> Steve
>
>
>
From: Birkir R. Gunnarsson
Date: Thu, May 02 2019 8:49AM
Subject: Re: Landmarks
← Previous message | Next message →
Axe flags a page where some content is contained in landmarks and
other content isn't as a best practice issue, which I think is
reasonable.
I haven't tested situations where you have multiple banner, main or
contentinfo regions per page, it should be the same (slight misuse of
ARIA) though I know the ARIA group has had debates about whether this
is true, a page could contain an embedded document with its own
landmark structure, or be sectioned in such a way as justifying two
main landmarks.
I personally disagree.
I think all pages should have banner, main and contentinfo (except
pages with no headers or footers whatsoever, those are rare but do
exist).
I insist on that in my reviews, I also flag multiple
banner/main/contentinfo landmarks as a fail.
Between these 3 you should have the whole pae covered.
There are the occasional borderline cases, such as breadcrumbs, which
I recommend role="navigation" on, these are sometimes displayed
between header and main, or main and footer.
Sometimes you have totally irrelevant contnt on the page, in which
case I recommend the complementary role, things like standard ad
banners for sections of pages, weather information for a hotel page
and similar.
I think landmarks are worth fighting for, at least the minimal use of
basic landmarks. AS steve elegantly pointed out, they convey more
information than headings alone and they are also standard across
pages whereas heading structure and text depends on the page content
and is less consistent.
On 5/2/19, Isabel Holdsworth < = EMAIL ADDRESS REMOVED = > wrote:
> I kind of feel like either use them correctly or not at all. Does this
> seem a reasonable enough approach?
>
> Steve, you make a very good point about landmarks denoting the end as
> well as the start, which mechanisms such as H1 headings and skip links
> can't do.
>
> Cheers, Isabel
>
> On 02/05/2019, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:
>> The absence of landmarks is certainly not the most serious of
>> accessibility
>> barriers, but landmarks have the advantage that they convey both the
>> start
>> and end of sections of content, which headings do not.
>>
>> Page headers and footers are usually conveyed visually in a totally
>> unambiguous manner. SC 1.3.1 requires that this structure is conveyed
>> programmatically, and landmarks are the best way to do that. In fact, how
>> else would you do so? I struggle to see how this cannot be a
>> non-compliance.
>>
>> Steve
>>
>>
>>
From: John Foliot
Date: Thu, May 02 2019 9:31AM
Subject: Re: Landmarks
← Previous message | Next message →
Steve writes:
> I struggle to see how this cannot be a non-compliance.
As Jon Avila notes, this was heavily debated at the W3C. SC 1.3.1 simply
states: *Information, structure, and relationships conveyed through
presentation can be programmatically determined or are available in text.*
Effectively, the argument goes like this: When WCAG 2.0 was published,
"landmarks" (whether ARIA or HTML5) were not really a thing that could be
reliably counted upon (ref: AT support), and so as such, you could still be
in WCAG 2.0 conformance without the use of landmarks, if other mechanisms
were provided to convey document structure (i.e. headings, etc.).
Interestingly, WebAIM's very first SR survey was conducted right around the
same time that WCAG 2.0 was published, and that initial survey concluded
that a majority of daily SR users were using Headings as a principle means
of content navigation - relying on the structure they afforded at that time
(and still do today): https://webaim.org/projects/screenreadersurvey/
It is important to also remember that WCAG conformance is not based upon
techniques, but rather outcomes, and so while using landmarks today is
pretty much a no-brainer (it is an extremely *effective* way of meeting the
requirement), failing to use landmarks cannot be a non-conformance outcome*
if document structure can be determined with other methods (including - and
many people miss this nuance - *"...or (is) available in text"*), which is
why a Failure Technique of that nature was rejected.
I'd also tend to agree with Birkir: if a site *does* use landmarks, I'd
expect to see at a minimum the "big 3" as well (Header/Main/Footer), but
again, I'd be hard pressed to fail a site if all they used were Header and
Footer, because failing to use any of the landmarks (ARIA or HTML5) is not,
in-and-of-itself, a failure. There is nothing in any W3C specification
(Recommendation) that explicitly states you have to use a minimum set, or
specific combination, of landmarks: it's bad development practice perhaps,
but not an explicit failure. (Bottom Line: using landmarks is a great Best
Practice, but that's it.)
(* there was also concern that if a Failure Technique like that was
written, sites/pages that did not use landmarks but were still WCAG
compliant at time of publishing would suddenly fall out of conformance,
which we had to avoid at all costs. Backward compatibility is and remains a
crucial concern, both on this specific topic, but also overall during the
WCAG 2.1 and now 2.2 development phases.)
HTH
JF
On Thu, May 2, 2019 at 8:59 AM Steve Green < = EMAIL ADDRESS REMOVED = >
wrote:
> The absence of landmarks is certainly not the most serious of
> accessibility barriers, but landmarks have the advantage that they convey
> both the start and end of sections of content, which headings do not.
>
> Page headers and footers are usually conveyed visually in a totally
> unambiguous manner. SC 1.3.1 requires that this structure is conveyed
> programmatically, and landmarks are the best way to do that. In fact, how
> else would you do so? I struggle to see how this cannot be a non-compliance.
>
> Steve
>
--
*John Foliot* | Principal Accessibility Strategist | W3C AC Representative
Deque Systems - Accessibility for Good
deque.com
From: Isabel Holdsworth
Date: Fri, May 03 2019 5:07AM
Subject: Re: Landmarks
← Previous message | No next message
Thanks John and everyone for weighing in on thiss topic. I felt this
was probably how things stood: that although it's sloppy mark-up, it's
not a technical fail.
Cheers and have a great weekend, Isabel
On 02/05/2019, John Foliot < = EMAIL ADDRESS REMOVED = > wrote:
> Steve writes:
>
>> I struggle to see how this cannot be a non-compliance.
>
> As Jon Avila notes, this was heavily debated at the W3C. SC 1.3.1 simply
> states: *Information, structure, and relationships conveyed through
> presentation can be programmatically determined or are available in text.*
>
> Effectively, the argument goes like this: When WCAG 2.0 was published,
> "landmarks" (whether ARIA or HTML5) were not really a thing that could be
> reliably counted upon (ref: AT support), and so as such, you could still be
> in WCAG 2.0 conformance without the use of landmarks, if other mechanisms
> were provided to convey document structure (i.e. headings, etc.).
> Interestingly, WebAIM's very first SR survey was conducted right around the
> same time that WCAG 2.0 was published, and that initial survey concluded
> that a majority of daily SR users were using Headings as a principle means
> of content navigation - relying on the structure they afforded at that time
> (and still do today): https://webaim.org/projects/screenreadersurvey/
>
> It is important to also remember that WCAG conformance is not based upon
> techniques, but rather outcomes, and so while using landmarks today is
> pretty much a no-brainer (it is an extremely *effective* way of meeting the
> requirement), failing to use landmarks cannot be a non-conformance outcome*
> if document structure can be determined with other methods (including - and
> many people miss this nuance - *"...or (is) available in text"*), which is
> why a Failure Technique of that nature was rejected.
>
> I'd also tend to agree with Birkir: if a site *does* use landmarks, I'd
> expect to see at a minimum the "big 3" as well (Header/Main/Footer), but
> again, I'd be hard pressed to fail a site if all they used were Header and
> Footer, because failing to use any of the landmarks (ARIA or HTML5) is not,
> in-and-of-itself, a failure. There is nothing in any W3C specification
> (Recommendation) that explicitly states you have to use a minimum set, or
> specific combination, of landmarks: it's bad development practice perhaps,
> but not an explicit failure. (Bottom Line: using landmarks is a great Best
> Practice, but that's it.)
>
> (* there was also concern that if a Failure Technique like that was
> written, sites/pages that did not use landmarks but were still WCAG
> compliant at time of publishing would suddenly fall out of conformance,
> which we had to avoid at all costs. Backward compatibility is and remains a
> crucial concern, both on this specific topic, but also overall during the
> WCAG 2.1 and now 2.2 development phases.)
>
> HTH
>
> JF
>
>
> On Thu, May 2, 2019 at 8:59 AM Steve Green < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> The absence of landmarks is certainly not the most serious of
>> accessibility barriers, but landmarks have the advantage that they convey
>> both the start and end of sections of content, which headings do not.
>>
>> Page headers and footers are usually conveyed visually in a totally
>> unambiguous manner. SC 1.3.1 requires that this structure is conveyed
>> programmatically, and landmarks are the best way to do that. In fact, how
>> else would you do so? I struggle to see how this cannot be a
>> non-compliance.
>>
>> Steve
>>
> --
> *John Foliot* | Principal Accessibility Strategist | W3C AC Representative
> Deque Systems - Accessibility for Good
> deque.com
> > > > >