E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 37 (In chronological order)

From: Christine Hogenkamp
Date: Tue, Mar 23 2021 2:07PM
Subject: The importance of landmarks to screen readers?
No previous message | Next message →

Hello,

My dev team and I are currently having a discussion about the importance of
landmarks in websites. I was under the impression that the guidance of WCAG
suggests that each webpage should have at least one or two landmarks per
page, to help give screenreader users the ability to understand the overall
layout of the page, for example that the page has at least the landmarks:

- a header (for overall site info such as website name)
- a nav (with links to different pages within the site or different
sections of the page if it's a page with a lot of different content such as
a long scroll type website)
- a main for the content of the page

We were working on a website that had a nav landmark that was by default
hidden as a landmark when the page loaded (in NVDA it was not showing as
anything under the Landmarks list in Elements List) and only became visible
as a landmark once a hamburger menu was opened.

I had flagged this as a WCAG failure, because the user has no way to know
the nav landmark is there until they open the nav by hamburger button (and
how can they open the nav when they don't know it's there? a sort of
catch-22 situation) and I had assumed that screenreader users would want
the nav landmark to be visible by default, either accessible by keyboard
shortcut or by the Landmarks list.

Have I given the nav landmark identity too much importance, that it must be
identified by the screenreader officially as a nav landmark by default when
the page loads? If the nav was clearly labelled for what it is (ie Main
menu) and clear instructions are given for opening the menu by the
hamburger icon, and otherwise is read out clearly by the screenreader and
navigable by keyboard, would that be considered sufficient for passing the
intent of WCAG's guidelines? Or do screen reader users first look at the
list of page landmarks to help them move quickly between different parts of
the page?


*x*
*Christine Hogenkamp (She, Her)*
Front-end Developer

CONTEXT CREATIVE
317 ADELAIDE ST. W., #500 | TORONTO, ON CANADA | M5V 1P9
<https://maps.google.com/?q17+ADELAIDE+ST.+W.,+%23500%C2%A0+%7C%C2%A0+TORONTO,+ON+CANADA%C2%A0+%7C%C2%A0+M5V+1P9&entry=gmail&source=g>

From: glen walker
Date: Tue, Mar 23 2021 2:32PM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

You often find scanning tools that flag a lack of landmarks as an error.
Or more frequently, they're marked as a "best practice" but many people
miss the "best practice" part and think *all* errors found by the tool are
required to be fixed.

Nothing in WCAG requires landmarks directly. They can absolutely be
helpful for navigating the page (with assistive technology) and aiding in
2.4.1 conformance. They can also be helpful in satisfying 1.3.1 since you
can often visually discern a "relationship" among elements that should be
programmatically conveyed. But it can be a bit subjective on whether
landmarks are really "required".

But does it matter if they are technically needed or not? From a UX
perspective, they're super handy so go ahead and implement them. If
browsers would implement a native way to navigate by landmarks then more
users could benefit from them, especially keyboard users.

And if you are going to implement them, lean towards using native semantic
html elements first before relying on ARIA roles. Use <header>, <footer>,
<main>, <nav>, <section>, <aside>, etc. And other than <header>, <footer>,
or <main>, you should also specify an aria-label for the landmark.

From: Laura Fathauer
Date: Tue, Mar 23 2021 2:40PM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

As glen has indicated, the landmarks are one technique for meeting 2.4.1
Bypass Blocks. To meet the testable success criteria 2.4.1, there must be
at least one "mechanism
<https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-skip.html#mechanismdef>
[...] available to bypass blocks of content that are repeated on multiple Web
pages
<https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-skip.html#webpagedef>.
(Level A). Skip links are another technique to meet 2.4.1; so if you have
skip links, you've likely met 2.4.1, and landmarks are an additional way to
meet 2.4.1.

Having the landmark only appear when the menu is expanded I wouldn't view
as particularly helpful; the focus is already within the menu, so the
navigation landmark most likely wouldn't be used for navigation at all on
the overall page.

Laura

On Tue, Mar 23, 2021 at 4:08 PM Christine Hogenkamp <
= EMAIL ADDRESS REMOVED = > wrote:

> Hello,
>
> My dev team and I are currently having a discussion about the importance of
> landmarks in websites. I was under the impression that the guidance of WCAG
> suggests that each webpage should have at least one or two landmarks per
> page, to help give screenreader users the ability to understand the overall
> layout of the page, for example that the page has at least the landmarks:
>
> - a header (for overall site info such as website name)
> - a nav (with links to different pages within the site or different
> sections of the page if it's a page with a lot of different content such as
> a long scroll type website)
> - a main for the content of the page
>
> We were working on a website that had a nav landmark that was by default
> hidden as a landmark when the page loaded (in NVDA it was not showing as
> anything under the Landmarks list in Elements List) and only became visible
> as a landmark once a hamburger menu was opened.
>
> I had flagged this as a WCAG failure, because the user has no way to know
> the nav landmark is there until they open the nav by hamburger button (and
> how can they open the nav when they don't know it's there? a sort of
> catch-22 situation) and I had assumed that screenreader users would want
> the nav landmark to be visible by default, either accessible by keyboard
> shortcut or by the Landmarks list.
>
> Have I given the nav landmark identity too much importance, that it must be
> identified by the screenreader officially as a nav landmark by default when
> the page loads? If the nav was clearly labelled for what it is (ie Main
> menu) and clear instructions are given for opening the menu by the
> hamburger icon, and otherwise is read out clearly by the screenreader and
> navigable by keyboard, would that be considered sufficient for passing the
> intent of WCAG's guidelines? Or do screen reader users first look at the
> list of page landmarks to help them move quickly between different parts of
> the page?
>
>
> *x*
> *Christine Hogenkamp (She, Her)*
> Front-end Developer
>
> CONTEXT CREATIVE
> 317 ADELAIDE ST. W., #500 | TORONTO, ON CANADA | M5V 1P9
> <https://maps.google.com/?q17+ADELAIDE+ST.+W
> .,+%23500%C2%A0+%7C%C2%A0+TORONTO,+ON+CANADA%C2%A0+%7C%C2%A0+M5V+1P9&entry=gmail&source=g>
> > > > >

From: David Engebretson Jr.
Date: Tue, Mar 23 2021 4:57PM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

I agree with Glen's comments and would like to put in a cent or two regarding aria-label's in landmark/regions:

If you are using a <nav>, please don't put the word "navigation" in your aria-label. Screen readers will read an aria-label="main site navigation" as
"main site navigation navigation region. The repetition can be redundant and cognitively taxing.

It's a common problem in region naming so I'd suggest that a manual review of how assistive technologies read the landmark/region is super important to reduce the cognitive load on your users.

Thanks!
David


-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen walker
Sent: Tuesday, March 23, 2021 1:33 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] The importance of landmarks to screen readers?

You often find scanning tools that flag a lack of landmarks as an error.
Or more frequently, they're marked as a "best practice" but many people miss the "best practice" part and think *all* errors found by the tool are required to be fixed.

Nothing in WCAG requires landmarks directly. They can absolutely be helpful for navigating the page (with assistive technology) and aiding in
2.4.1 conformance. They can also be helpful in satisfying 1.3.1 since you can often visually discern a "relationship" among elements that should be programmatically conveyed. But it can be a bit subjective on whether landmarks are really "required".

But does it matter if they are technically needed or not? From a UX perspective, they're super handy so go ahead and implement them. If browsers would implement a native way to navigate by landmarks then more users could benefit from them, especially keyboard users.

And if you are going to implement them, lean towards using native semantic html elements first before relying on ARIA roles. Use <header>, <footer>, <main>, <nav>, <section>, <aside>, etc. And other than <header>, <footer>, or <main>, you should also specify an aria-label for the landmark.

From: Bart Simons
Date: Wed, Mar 24 2021 5:19AM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

> you should also specify an aria-label for the landmark.

I would like to add some nuances to this statement.
Taking the website http://www.keat.gr/index.php/en/ as an example.

When using a role="search" there is really no need to label that section
with the word search that you labelledby from a visually hidden heading:
<section role="search" aria-labelledby="zf--search--section-heading">
<h2 id="zf--search--section-heading" class="zf--section-heading
visually-hidden">Search</h2>

We also don't need a section labelled "footer" inside the <footer> element:
<footer role="contentinfo">
<section aria-labelledby="zf--footer-content--section-heading"
<h2 id="zf--footer-content--section-heading"
class="visually-hidden">Footer</h2>

Further I'd limit the number of occurences of the same landmark on a
page rather than trying to find descriptive labels. They clearly ran out
of inspiration when they came up with
"complementary content (lower)"

It is not trivial to label a set of nav sections in a useful way. My
plea is to limit the number of landmarks avoiding the necessity to label
them.

Regards

Bart Simons


Op 23/03/2021 om 21:32 schreef glen walker:

> You often find scanning tools that flag a lack of landmarks as an error.
> Or more frequently, they're marked as a "best practice" but many people
> miss the "best practice" part and think *all* errors found by the tool are
> required to be fixed.
>
> Nothing in WCAG requires landmarks directly. They can absolutely be
> helpful for navigating the page (with assistive technology) and aiding in
> 2.4.1 conformance. They can also be helpful in satisfying 1.3.1 since you
> can often visually discern a "relationship" among elements that should be
> programmatically conveyed. But it can be a bit subjective on whether
> landmarks are really "required".
>
> But does it matter if they are technically needed or not? From a UX
> perspective, they're super handy so go ahead and implement them. If
> browsers would implement a native way to navigate by landmarks then more
> users could benefit from them, especially keyboard users.
>
> And if you are going to implement them, lean towards using native semantic
> html elements first before relying on ARIA roles. Use <header>, <footer>,
> <main>, <nav>, <section>, <aside>, etc. And other than <header>, <footer>,
> or <main>, you should also specify an aria-label for the landmark.
> > > >

From: Birkir R. Gunnarsson
Date: Wed, Mar 24 2021 5:47AM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

I agree with Bart
My general approach as an accessibility lead (and my experience as a
screen reader user) is to recommend that you identify the header, main
content, and footer of a webpage using landmarks (either the proper
HTML elements or using the proper landmark roles), this is
particularly true if the 3 sections of the page are visually distinct
and if the header/footer are standard across multipple pages (whereas
the main content is unique to the page).
No accessible names are required.
I typically find that "less is more" when it comes to landmarks so I
recommend other landmark roles only in certain situations.

If you have a persistent collection of links with a common purpose or
an accordion that you can open and that remains open when you navigate
away from it, then I recommend the navigation landmark with an
accessible name.
e.g.
<nav aria-label="accounts">
<ul>
<li>link to account 1</li>
<li>Link to account 2</li>
..
</ul>
</nav>
or
<button aria-expanded="true" id="a1">Promotions</button>
<nav aria-labelledby="a1">
link 1
link 2
</nav>

One advantage of landmarks of headings is that you can see the
boundries of the landmarks with a screen reader (the beginning and the
end). Sometimes this is important if otherwise you wouldn't be sure
(e.g. if the section after the landmark region does not start with a
heading).
The guidance would be too detailed to put in an email (especially
before 8am and my first cup of coffee), but my general message is not
to overdo landmarks. They add verbosity and many people do not know
how to use them.
Mark the 3 sections of the page and use a landmark if you feel other
content is strongly related (strong enough that you can easily come up
with a name for it), especially if you think the boundries of that
content need to be made clear to the user.

On 3/24/21, Bart Simons < = EMAIL ADDRESS REMOVED = > wrote:
> > you should also specify an aria-label for the landmark.
>
> I would like to add some nuances to this statement.
> Taking the website http://www.keat.gr/index.php/en/ as an example.
>
> When using a role="search" there is really no need to label that section
> with the word search that you labelledby from a visually hidden heading:
> <section role="search" aria-labelledby="zf--search--section-heading">
> <h2 id="zf--search--section-heading" class="zf--section-heading
> visually-hidden">Search</h2>
>
> We also don't need a section labelled "footer" inside the <footer> element:
> <footer role="contentinfo">
> <section aria-labelledby="zf--footer-content--section-heading"
> <h2 id="zf--footer-content--section-heading"
> class="visually-hidden">Footer</h2>
>
> Further I'd limit the number of occurences of the same landmark on a
> page rather than trying to find descriptive labels. They clearly ran out
> of inspiration when they came up with
> "complementary content (lower)"
>
> It is not trivial to label a set of nav sections in a useful way. My
> plea is to limit the number of landmarks avoiding the necessity to label
> them.
>
> Regards
>
> Bart Simons
>
>
> Op 23/03/2021 om 21:32 schreef glen walker:
>
>> You often find scanning tools that flag a lack of landmarks as an error.
>> Or more frequently, they're marked as a "best practice" but many people
>> miss the "best practice" part and think *all* errors found by the tool are
>> required to be fixed.
>>
>> Nothing in WCAG requires landmarks directly. They can absolutely be
>> helpful for navigating the page (with assistive technology) and aiding in
>> 2.4.1 conformance. They can also be helpful in satisfying 1.3.1 since you
>> can often visually discern a "relationship" among elements that should be
>> programmatically conveyed. But it can be a bit subjective on whether
>> landmarks are really "required".
>>
>> But does it matter if they are technically needed or not? From a UX
>> perspective, they're super handy so go ahead and implement them. If
>> browsers would implement a native way to navigate by landmarks then more
>> users could benefit from them, especially keyboard users.
>>
>> And if you are going to implement them, lean towards using native semantic
>> html elements first before relying on ARIA roles. Use <header>, <footer>,
>> <main>, <nav>, <section>, <aside>, etc. And other than <header>,
>> <footer>,
>> or <main>, you should also specify an aria-label for the landmark.
>> >> >> >> >
>
> > > > >


--
Work hard. Have fun. Make history.

From: Andrews, David B (DEED)
Date: Wed, Mar 24 2021 7:39AM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

This site did have a log of regions!

I don't know what it is like visually, but when you arrow through, using JAWS, versus tabbing through, they are quite different experiences.

Dave




-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Bart Simons
Sent: Wednesday, March 24, 2021 6:19 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] The importance of landmarks to screen readers?

This message may be from an external email source.
Do not select links or open attachments unless verified. Report all suspicious emails to Minnesota IT Services Security Operations Center.

> you should also specify an aria-label for the landmark.

I would like to add some nuances to this statement.
Taking the website https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keat.gr%2Findex.php%2Fen%2F&amp;data%7C01%7Cdavid.b.andrews%40state.mn.us%7C33e0daa1b1174505aade08d8eeb66c92%7Ceb14b04624c445198f26b89c2159828c%7C0%7C1%7C637521814580151771%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Q1OthYzP8Ne8T9b%2B0hrVieqzooUc%2BOx1PVMoJnNeh1k%3D&amp;reserved=0 as an example.

When using a role="search" there is really no need to label that section with the word search that you labelledby from a visually hidden heading:
<section role="search" aria-labelledby="zf--search--section-heading">
<h2 id="zf--search--section-heading" class="zf--section-heading visually-hidden">Search</h2>

We also don't need a section labelled "footer" inside the <footer> element:
<footer role="contentinfo">
<section aria-labelledby="zf--footer-content--section-heading"
<h2 id="zf--footer-content--section-heading"
class="visually-hidden">Footer</h2>

Further I'd limit the number of occurences of the same landmark on a page rather than trying to find descriptive labels. They clearly ran out of inspiration when they came up with "complementary content (lower)"

It is not trivial to label a set of nav sections in a useful way. My plea is to limit the number of landmarks avoiding the necessity to label them.

Regards

Bart Simons


Op 23/03/2021 om 21:32 schreef glen walker:

> You often find scanning tools that flag a lack of landmarks as an error.
> Or more frequently, they're marked as a "best practice" but many
> people miss the "best practice" part and think *all* errors found by
> the tool are required to be fixed.
>
> Nothing in WCAG requires landmarks directly. They can absolutely be
> helpful for navigating the page (with assistive technology) and aiding
> in
> 2.4.1 conformance. They can also be helpful in satisfying 1.3.1 since
> you can often visually discern a "relationship" among elements that
> should be programmatically conveyed. But it can be a bit subjective
> on whether landmarks are really "required".
>
> But does it matter if they are technically needed or not? From a UX
> perspective, they're super handy so go ahead and implement them. If
> browsers would implement a native way to navigate by landmarks then
> more users could benefit from them, especially keyboard users.
>
> And if you are going to implement them, lean towards using native
> semantic html elements first before relying on ARIA roles. Use
> <header>, <footer>, <main>, <nav>, <section>, <aside>, etc. And other
> than <header>, <footer>, or <main>, you should also specify an aria-label for the landmark.
> > > https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist.
> webaim.org%2F&amp;data%7C01%7Cdavid.b.andrews%40state.mn.us%7C33e0d
> aa1b1174505aade08d8eeb66c92%7Ceb14b04624c445198f26b89c2159828c%7C0%7C1
> %7C637521814580151771%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ
> IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=6Jlyeul6%2
> FTzHO5NXsHk6%2FrWZjxdR9HdBada5cvypTik%3D&amp;reserved=0
> List archives at
> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwebai
> m.org%2Fdiscussion%2Farchives&amp;data%7C01%7Cdavid.b.andrews%40sta
> te.mn.us%7C33e0daa1b1174505aade08d8eeb66c92%7Ceb14b04624c445198f26b89c
> 2159828c%7C0%7C1%7C637521814580161727%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;
> sdata=bpfHCxyz4S9ktHRZxmcXzWFEoQ6OcUTbK2JoSW6I3yU%3D&amp;reserved=0
>

From: Maraikayar Prem Nawaz
Date: Thu, Mar 25 2021 12:23AM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

The frequent use of landmarks and regions has continually decreased from
43.8% in 2014, to 38.6% in 2015, to 30.5% in 2017, to 26.6% on this survey.
It's difficult to know the reasons for this. It could be due to infrequent
or improper usage of landmarks/regions in pages. Or perhaps because other
mechanisms are continually better.
https://webaim.org/projects/screenreadersurvey8/#landmarks
Browsing by headings has a huge acceptance than landmarks.


On Wed, Mar 24, 2021 at 7:09 PM Andrews, David B (DEED) <
= EMAIL ADDRESS REMOVED = > wrote:

> This site did have a log of regions!
>
> I don't know what it is like visually, but when you arrow through, using
> JAWS, versus tabbing through, they are quite different experiences.
>
> Dave
>
>
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Bart Simons
> Sent: Wednesday, March 24, 2021 6:19 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] The importance of landmarks to screen readers?
>
> This message may be from an external email source.
> Do not select links or open attachments unless verified. Report all
> suspicious emails to Minnesota IT Services Security Operations Center.
>
> >
> > you should also specify an aria-label for the landmark.
>
> I would like to add some nuances to this statement.
> Taking the website
> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keat.gr%2Findex.php%2Fen%2F&amp;data%7C01%7Cdavid.b.andrews%40state.mn.us%7C33e0daa1b1174505aade08d8eeb66c92%7Ceb14b04624c445198f26b89c2159828c%7C0%7C1%7C637521814580151771%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Q1OthYzP8Ne8T9b%2B0hrVieqzooUc%2BOx1PVMoJnNeh1k%3D&amp;reserved=0
> as an example.
>
> When using a role="search" there is really no need to label that section
> with the word search that you labelledby from a visually hidden heading:
> <section role="search" aria-labelledby="zf--search--section-heading">
> <h2 id="zf--search--section-heading" class="zf--section-heading
> visually-hidden">Search</h2>
>
> We also don't need a section labelled "footer" inside the <footer> element:
> <footer role="contentinfo">
> <section aria-labelledby="zf--footer-content--section-heading"
> <h2 id="zf--footer-content--section-heading"
> class="visually-hidden">Footer</h2>
>
> Further I'd limit the number of occurences of the same landmark on a page
> rather than trying to find descriptive labels. They clearly ran out of
> inspiration when they came up with "complementary content (lower)"
>
> It is not trivial to label a set of nav sections in a useful way. My plea
> is to limit the number of landmarks avoiding the necessity to label them.
>
> Regards
>
> Bart Simons
>
>
> Op 23/03/2021 om 21:32 schreef glen walker:
>
> > You often find scanning tools that flag a lack of landmarks as an error.
> > Or more frequently, they're marked as a "best practice" but many
> > people miss the "best practice" part and think *all* errors found by
> > the tool are required to be fixed.
> >
> > Nothing in WCAG requires landmarks directly. They can absolutely be
> > helpful for navigating the page (with assistive technology) and aiding
> > in
> > 2.4.1 conformance. They can also be helpful in satisfying 1.3.1 since
> > you can often visually discern a "relationship" among elements that
> > should be programmatically conveyed. But it can be a bit subjective
> > on whether landmarks are really "required".
> >
> > But does it matter if they are technically needed or not? From a UX
> > perspective, they're super handy so go ahead and implement them. If
> > browsers would implement a native way to navigate by landmarks then
> > more users could benefit from them, especially keyboard users.
> >
> > And if you are going to implement them, lean towards using native
> > semantic html elements first before relying on ARIA roles. Use
> > <header>, <footer>, <main>, <nav>, <section>, <aside>, etc. And other
> > than <header>, <footer>, or <main>, you should also specify an
> aria-label for the landmark.
> > > > > > https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist.
> > webaim.org%2F&amp;data%7C01%7Cdavid.b.andrews%40state.mn.us%7C33e0d
> > aa1b1174505aade08d8eeb66c92%7Ceb14b04624c445198f26b89c2159828c%7C0%7C1
> > %7C637521814580151771%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ
> > IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=6Jlyeul6%2
> > FTzHO5NXsHk6%2FrWZjxdR9HdBada5cvypTik%3D&amp;reserved=0
> > List archives at
> > https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwebai
> > m.org%2Fdiscussion%2Farchives&amp;data%7C01%7Cdavid.b.andrews%40sta
> > te.mn.us%7C33e0daa1b1174505aade08d8eeb66c92%7Ceb14b04624c445198f26b89c
> > 2159828c%7C0%7C1%7C637521814580161727%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;
> > sdata=bpfHCxyz4S9ktHRZxmcXzWFEoQ6OcUTbK2JoSW6I3yU%3D&amp;reserved=0
> > >
>
> > > https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist.webaim.org%2F&amp;data%7C01%7Cdavid.b.andrews%40state.mn.us%7C33e0daa1b1174505aade08d8eeb66c92%7Ceb14b04624c445198f26b89c2159828c%7C0%7C1%7C637521814580161727%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=u5fjKBc3KkQhb3GNO9rnf4RfT%2BVdzC5%2FZUKPDdIvZTs%3D&amp;reserved=0
> List archives at
> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwebaim.org%2Fdiscussion%2Farchives&amp;data%7C01%7Cdavid.b.andrews%40state.mn.us%7C33e0daa1b1174505aade08d8eeb66c92%7Ceb14b04624c445198f26b89c2159828c%7C0%7C1%7C637521814580161727%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=bpfHCxyz4S9ktHRZxmcXzWFEoQ6OcUTbK2JoSW6I3yU%3D&amp;reserved=0
> > > > > >

From: Mark Magennis
Date: Thu, Mar 25 2021 6:21AM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

The survey results are very interesting and perhaps surprising. However, one thing to note is that the question asks whether people navigate by landmarks. Even if they don't, landmarks may still be useful to them by providing information about the structure as they go through it using other navigation methods.

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Maraikayar Prem Nawaz
Sent: 25 March 2021 06:23
Cc: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [EXTERNAL] Re: [WebAIM] The importance of landmarks to screen readers?

The frequent use of landmarks and regions has continually decreased from 43.8% in 2014, to 38.6% in 2015, to 30.5% in 2017, to 26.6% on this survey.
It's difficult to know the reasons for this. It could be due to infrequent or improper usage of landmarks/regions in pages. Or perhaps because other mechanisms are continually better.
https://webaim.org/projects/screenreadersurvey8/#landmarks
Browsing by headings has a huge acceptance than landmarks.


On Wed, Mar 24, 2021 at 7:09 PM Andrews, David B (DEED) < = EMAIL ADDRESS REMOVED = > wrote:

> This site did have a log of regions!
>
> I don't know what it is like visually, but when you arrow through,
> using JAWS, versus tabbing through, they are quite different experiences.
>
> Dave
>
>
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Bart Simons
> Sent: Wednesday, March 24, 2021 6:19 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] The importance of landmarks to screen readers?
>
> This message may be from an external email source.
> Do not select links or open attachments unless verified. Report all
> suspicious emails to Minnesota IT Services Security Operations Center.
>
> >
> > you should also specify an aria-label for the landmark.
>
> I would like to add some nuances to this statement.
> Taking the website
> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.k
> eat.gr%2Findex.php%2Fen%2F&amp;data%7C01%7Cdavid.b.andrews%40state.
> mn.us%7C33e0daa1b1174505aade08d8eeb66c92%7Ceb14b04624c445198f26b89c215
> 9828c%7C0%7C1%7C637521814580151771%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sda
> ta=Q1OthYzP8Ne8T9b%2B0hrVieqzooUc%2BOx1PVMoJnNeh1k%3D&amp;reserved=0
> as an example.
>
> When using a role="search" there is really no need to label that
> section with the word search that you labelledby from a visually hidden heading:
> <section role="search" aria-labelledby="zf--search--section-heading">
> <h2 id="zf--search--section-heading" class="zf--section-heading
> visually-hidden">Search</h2>
>
> We also don't need a section labelled "footer" inside the <footer> element:
> <footer role="contentinfo">
> <section aria-labelledby="zf--footer-content--section-heading"
> <h2 id="zf--footer-content--section-heading"
> class="visually-hidden">Footer</h2>
>
> Further I'd limit the number of occurences of the same landmark on a
> page rather than trying to find descriptive labels. They clearly ran
> out of inspiration when they came up with "complementary content (lower)"
>
> It is not trivial to label a set of nav sections in a useful way. My
> plea is to limit the number of landmarks avoiding the necessity to label them.
>
> Regards
>
> Bart Simons
>
>
> Op 23/03/2021 om 21:32 schreef glen walker:
>
> > You often find scanning tools that flag a lack of landmarks as an error.
> > Or more frequently, they're marked as a "best practice" but many
> > people miss the "best practice" part and think *all* errors found by
> > the tool are required to be fixed.
> >
> > Nothing in WCAG requires landmarks directly. They can absolutely be
> > helpful for navigating the page (with assistive technology) and
> > aiding in
> > 2.4.1 conformance. They can also be helpful in satisfying 1.3.1
> > since you can often visually discern a "relationship" among elements
> > that should be programmatically conveyed. But it can be a bit
> > subjective on whether landmarks are really "required".
> >
> > But does it matter if they are technically needed or not? From a UX
> > perspective, they're super handy so go ahead and implement them. If
> > browsers would implement a native way to navigate by landmarks then
> > more users could benefit from them, especially keyboard users.
> >
> > And if you are going to implement them, lean towards using native
> > semantic html elements first before relying on ARIA roles. Use
> > <header>, <footer>, <main>, <nav>, <section>, <aside>, etc. And
> > other than <header>, <footer>, or <main>, you should also specify an
> aria-label for the landmark.
> > > > > > https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist.
> > webaim.org%2F&amp;data%7C01%7Cdavid.b.andrews%40state.mn.us%7C33e
> > 0d
> > aa1b1174505aade08d8eeb66c92%7Ceb14b04624c445198f26b89c2159828c%7C0%7
> > C1
> > %7C637521814580151771%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> > JQ
> > IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=6Jlyeul6
> > %2
> > FTzHO5NXsHk6%2FrWZjxdR9HdBada5cvypTik%3D&amp;reserved=0
> > List archives at
> > https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fweb
> > ai
> > m.org%2Fdiscussion%2Farchives&amp;data%7C01%7Cdavid.b.andrews%40s
> > ta
> > te.mn.us%7C33e0daa1b1174505aade08d8eeb66c92%7Ceb14b04624c445198f26b8
> > 9c
> > 2159828c%7C0%7C1%7C637521814580161727%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> > oi
> > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&am
> > p;
> > sdata=bpfHCxyz4S9ktHRZxmcXzWFEoQ6OcUTbK2JoSW6I3yU%3D&amp;reserved=0
> > >
>
> > > https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist.
> webaim.org%2F&amp;data%7C01%7Cdavid.b.andrews%40state.mn.us%7C33e0d
> aa1b1174505aade08d8eeb66c92%7Ceb14b04624c445198f26b89c2159828c%7C0%7C1
> %7C637521814580161727%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ
> IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=u5fjKBc3Kk
> Qhb3GNO9rnf4RfT%2BVdzC5%2FZUKPDdIvZTs%3D&amp;reserved=0
> List archives at
> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwebai
> m.org%2Fdiscussion%2Farchives&amp;data%7C01%7Cdavid.b.andrews%40sta
> te.mn.us%7C33e0daa1b1174505aade08d8eeb66c92%7Ceb14b04624c445198f26b89c
> 2159828c%7C0%7C1%7C637521814580161727%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;
> sdata=bpfHCxyz4S9ktHRZxmcXzWFEoQ6OcUTbK2JoSW6I3yU%3D&amp;reserved=0
> > > > archives at http://webaim.org/discussion/archives
> >

From: Michael Ausbun
Date: Thu, Mar 25 2021 7:30AM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

--_005_DM6PR02MB5034A17865AC9EE69EE4465692629DM6PR02MB5034namp_
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64

SSB0aGluayB0aGVyZSBhcmUgYSBudW1iZXIgb2YgdGhpbmdzIGF0IHBsYXksIGhlcmUuDQpGaXJz
dCBpcyB0aGUgaW1wbGVtZW50YXRpb24gb2YgbGFuZG1hcmtzIGF0LXNjYWxlLiBJbiBteSBleHBl
cmllbmNlLCB0aGUgdXNlIG9mIGxhbmRtYXJrcyBpcyBpbmNvbnNpc3RlbnQgZnJvbSBzaXRlIHRv
IHNpdGXigJRldmVuIHRoZSBtb3JlIHBlcnZhc2l2ZSBsYW5kbWFya3MsIGhlYWRlciwgZm9vdGVy
LCBhbmQgbWFpbi4NClRoZSBzZWNvbmQgZm9sbG93cyBmcm9tIHRoYXTigJRpZiB0aGUgaW1wbGVt
ZW50YXRpb24gaXMgaW5jb25zaXN0ZW50LCB0aGVuIHRob3VnaCB0aGUgbWV0aG9kIGZvciBuYXZp
Z2F0aW5nIG1heSBiZSB0YXVnaHQgaW4gY29tcHJlaGVuc2l2ZSBhY2Nlc3MgdGVjaG5vbG9neSB0
cmFpbmluZyBzZXNzaW9ucywgdGhlIGltcGxpY2l0LCBvciBleHBsaWNpdCwgYWR2aWNlIGlzIG5v
dCB0byByZWx5IG9uIGxhbmRtYXJrcy4gRHVlIHRvIDk4LjElIG9mIHdlYnNpdGVzIGZhbGxpbmcg
aW50byBwb3NzZXNzaW5nIGF1dG9tYXRlZGx5IGRldGVjdGVkIGFjY2Vzc2liaWxpdHkgYmFycmll
cnMsIG1vc3Qgc2NyZWVuIHJlYWRlciB1c2VycyBkb27igJl0IGxpdmUgaW4gdGhlIGRpZ2l0YWwg
d29ybGQsIGJ1dCBpbnN0ZWFkIGhhdmUgYSBjb21tb2RpZmllZCBleHBlcmllbmNlLiBUaGF0IGlz
LCB0aGUgdHJhbnNhY3Rpb25hbCByZWxhdGlvbnNoaXAgaXMgdmVyeSBtdWNoIHRhc2stb3JpZW50
ZWQuIEVmZmljaWVuY3kgaXMgcnVsZXI7IHRodXMsIGNvbnNpc3RlbnRseSBlZmZlY3RpdmUgbmF2
aWdhdGlvbmFsIG1ldGhvZHMgYXJlIHByaW9yaXRpemVkLg0KRmluYWxseSwgd2UgaGF2ZSB0byBr
ZWVwIGluIG1pbmQgY29tcHJlaGVuc2l2ZSByZWhhYmlsaXRhdGlvbiB0cmFpbmluZyBpcyBhIHJh
cml0eS4gR29vZCBjb21wcmVoZW5zaXZlIHRyYWluaW5nIGlzIGV2ZW4gbW9yZSByYXJlLiBMYW5k
bWFya3MgYXJlIHNvbWV3aGF0IGVzb3RlcmljIGFuZCB0aHVzIGRpc2NvdmVyYWJpbGl0eSBvciBh
c3NvY2lhdGlvbiBpcyB1bmxpa2VseSB0byBiZSBoaWdoIGFtb25nc3QgYSBtYWpvcml0eSBvZiB1
c2Vycy4NCg0KT24gdGhlIGZsaXAgc2lkZSB0aG91Z2gsIEkgdGhpbmsgbGFuZG1hcmtzIGFyZSBq
dXN0IGFzIGNyaXRpY2FsIGFzIGEgZ29vZCwgc2VxdWVudGlhbGx5IG9yZGVyZWQgaGVhZGluZyBz
dHJ1Y3R1cmUuIEluIG15IGV4cGVyaWVuY2UsICBpbnRlcmFjdGlvbnMgd2l0aCB0aGUgZGlnaXRh
bCB3b3JsZCBwYXJhbGxlbHMgaW50ZXJhY3Rpb24gd2l0aCB0aGUgcGh5c2ljYWwgZW52aXJvbm1l
bnQuIE5vbi12aXN1YWwgYWNjZXNzIHJlbGllcyBvbiBzdWJqZWN0aXZlIGV4cGVyaWVudGlhbCBr
bm93bGVkZ2UgYW5kIHN1YnNlcXVlbnQgY29nbml0aXZlIG1hcHBpbmcuIFRoZSBzZW1hbnRpYyBi
b3VuZGFyaWVzIGFyZSB0aGUgc3RyZWV0cywgdGhlIGxpZ2h0IHBvbGVzLCBhbmQgb3RoZXIgcGh5
c2ljYWwgb2JqZWN0cyB1c2VkIHRvIGNvbnN0cnVjdCB0aGUgY29nbml0aXZlIG1hcCBmb3Igb3Jp
ZW50YXRpb24gcHVycG9zZXMuIFRoZSBiYXJyaWVycyB3ZSBlbmNvdW50ZXIgYXJlIGEgcGllY2Ug
b2YgdGhlIGVudmlyb25tZW50YWwgY3VlcyB3aGljaCBzaGFwZSBvdXIgd29ybGR2aWV3LiBXaXRo
b3V0IGEgY2xlYXJseSBkZWZpbmVkIGNvZ25pdGl2ZSBzdHJ1Y3R1cmUsIGNvZ25pdGl2ZSBsb2Fk
IGlzIG5lY2Vzc2FyaWx5IGluY3JlYXNlZC4NCk1vc3Qgb2YgdGhpcyBwcm9jZXNzaW5nIGlzIHVu
Y29uc2Npb3VzLCBhcyB0aGVpcuKAlHR5cGljYWxseeKAlGlzIG5vIGxpZmUgb3IgZGVhdGggYXNz
b2NpYXRpb24gbGlrZSB3aXRoIHBoeXNpY2FsIG9yaWVudGF0aW9uLCBidXQgbmV2ZXIgdGhlIGxl
c3Mgc29tZSBwYXJhbGxlbCBkb2VzIGV4aXN0Lg0KUGxlYXNlIGxpc3RlbiB0byB0aGUgYWR2aWNl
IGZyb20gQmVya2lyIGFuZCBCYXJ0OyB2ZXJ5IGdvb2QgYWR2aWNlLg0KSnVzdCBhIGZldyBleHRy
YSB0aG91Z2h0cy4NCg0KDQoNCg0KLS0NCk1pY2hhZWwgRHVhbmUgQXVzYnVuLCBNQSwgQ1BXQSAo
SGUsIEhpcywgSGltKQ0KQWNjZXNzaWJpbGl0eSBTcGVjaWFsaXN0LCBQcm9ncmFtIERldmVsb3Bt
ZW50LA0KVW5pdmVyc2FsIERlc2lnbiBhbmQgQWNjZXNzaWJpbGl0eSBUZWFtDQpSdXN0b24sIExv
dWlzaWFuYQ0KDQpXZXN0ZXJuIEdvdmVybm9ycyBVbml2ZXJzaXR5DQo0MDAxIFNvdXRoIDcwMCBF
YXN0LCBTdWl0ZSA3MDANClNhbHQgTGFrZSBDaXR5LCBVVCA4NDEwNw0KTWljaGFlbC5hdXNidW5A
d2d1LmVkdTxtYWlsdG86TWljaGFlbC5hdXNidW5Ad2d1LmVkdT4NCg0KDQpbSUFBUCBDUFdBIHNt
YWxsIGNpcmN1bGFyIGJhZGdlIGFuZCBob3Jpem9udGFsIG5hbWUgbG9nbyBmb3IgSW50ZXJuYXRp
b25hbCBBc3NvY2lhdGlvbiBvZiBBY2Nlc3NpYmlsaXR5IFByb2Zlc3Npb25hbHMgKElBQVApIENl
cnRpZmllZCBQcm9mZXNzaW9uYWwgaW4gV2ViIEFjY2Vzc2liaWxpdHkgKENQV0EpIGNyZWRlbnRp
YWwuIFRvIHRoZSBsZWZ0IGlzIGEgZGFyayBibHVlIGNpcmNsZSB3aXRoIHRocmVlIGxpbmVzIG9m
IGNlbnRlcmVkIHdoaXRlIHRleHQgdGhhdCByZWFkOiBJQUFQIENlcnRpZmllZCBDUFdBLiBUaGVy
ZSBpcyBhIHNtYWxsZXIgc2lsdmVyIGNpcmNsZSB0aGF0IHN1cnJvdW5kcyB0aGUgZGFyayBibHVl
IGlubmVyIGNpcmNsZSB0aGF0IGRlc2lnbmF0ZXMgdGhlIENQV0EgY3JlZGVudGlhbCBjb2xvciBz
Y2hlbWUuIFRvIHRoZSByaWdodCwgdGhyZWUgbGluZXMgb2YgZGFyayBibHVlIHRleHQuIFRvcCB0
ZXh0IHJlYWRzIENlcnRpZmllZCBQcm9mZXNzaW9uYWwsIHNlY29uZCBsaW5lIHJlYWRzIGluIFdl
YiBBY2Nlc3NpYmlsaXR5LCB0aGlyZCBsaW5lIHJlYWRzIEludGVybmF0aW9uYWwgQXNzb2NpYXRp
b24gb2YgQWNjZXNzaWJpbGl0eSBQcm9mZXNzaW9uYWxzLl08aHR0cHM6Ly93d3cuYWNjZXNzaWJp
bGl0eWFzc29jaWF0aW9uLm9yZy9jcHdhPg0KDQpbSkFXUyBDZXJ0aWZpZWQsIDIwMjBdPGh0dHA6
Ly93d3cuZnJlZWRvbXNjaWVudGlmaWMuY29tL0NlcnRpZmljYXRpb24+DQoNCg0KDQoNCg0KRnJv
bTogV2ViQUlNLUZvcnVtIDx3ZWJhaW0tZm9ydW0tYm91bmNlc0BsaXN0LndlYmFpbS5vcmc+IE9u
IEJlaGFsZiBPZiBNYXJrIE1hZ2VubmlzDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMjUsIDIwMjEg
NzoyMiBBTQ0KVG86IFdlYkFJTSBEaXNjdXNzaW9uIExpc3QgPHdlYmFpbS1mb3J1bUBsaXN0Lndl
YmFpbS5vcmc+DQpTdWJqZWN0OiBSZTogW1dlYkFJTV0gVGhlIGltcG9ydGFuY2Ugb2YgbGFuZG1h
cmtzIHRvIHNjcmVlbiByZWFkZXJzPw0KDQpbRVhURVJOQUwgRU1BSUxdIFdBUk5JTkc6IFRoaXMg
ZW1haWwgb3JpZ2luYXRlZCBmcm9tIG91dHNpZGUgb2YgV2VzdGVybiBHb3Zlcm5vcnMgVW5pdmVy
c2l0eS4NCg0KVGhlIHN1cnZleSByZXN1bHRzIGFyZSB2ZXJ5IGludGVyZXN0aW5nIGFuZCBwZXJo
YXBzIHN1cnByaXNpbmcuIEhvd2V2ZXIsIG9uZSB0aGluZyB0byBub3RlIGlzIHRoYXQgdGhlIHF1
ZXN0aW9uIGFza3Mgd2hldGhlciBwZW9wbGUgbmF2aWdhdGUgYnkgbGFuZG1hcmtzLiBFdmVuIGlm
IHRoZXkgZG9uJ3QsIGxhbmRtYXJrcyBtYXkgc3RpbGwgYmUgdXNlZnVsIHRvIHRoZW0gYnkgcHJv
dmlkaW5nIGluZm9ybWF0aW9uIGFib3V0IHRoZSBzdHJ1Y3R1cmUgYXMgdGhleSBnbyB0aHJvdWdo
IGl0IHVzaW5nIG90aGVyIG5hdmlnYXRpb24gbWV0aG9kcy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCkZyb206IFdlYkFJTS1Gb3J1bSA8d2ViYWltLWZvcnVtLWJvdW5jZXNAbGlzdC53
ZWJhaW0ub3JnPG1haWx0bzp3ZWJhaW0tZm9ydW0tYm91bmNlc0BsaXN0LndlYmFpbS5vcmc+PiBP
biBCZWhhbGYgT2YgTWFyYWlrYXlhciBQcmVtIE5hd2F6DQpTZW50OiAyNSBNYXJjaCAyMDIxIDA2
OjIzDQpDYzogV2ViQUlNIERpc2N1c3Npb24gTGlzdCA8d2ViYWltLWZvcnVtQGxpc3Qud2ViYWlt
Lm9yZzxtYWlsdG86d2ViYWltLWZvcnVtQGxpc3Qud2ViYWltLm9yZz4+DQpTdWJqZWN0OiBbRVhU
RVJOQUxdIFJlOiBbV2ViQUlNXSBUaGUgaW1wb3J0YW5jZSBvZiBsYW5kbWFya3MgdG8gc2NyZWVu
IHJlYWRlcnM/DQoNClRoZSBmcmVxdWVudCB1c2Ugb2YgbGFuZG1hcmtzIGFuZCByZWdpb25zIGhh
cyBjb250aW51YWxseSBkZWNyZWFzZWQgZnJvbSA0My44JSBpbiAyMDE0LCB0byAzOC42JSBpbiAy
MDE1LCB0byAzMC41JSBpbiAyMDE3LCB0byAyNi42JSBvbiB0aGlzIHN1cnZleS4NCkl0J3MgZGlm
ZmljdWx0IHRvIGtub3cgdGhlIHJlYXNvbnMgZm9yIHRoaXMuIEl0IGNvdWxkIGJlIGR1ZSB0byBp
bmZyZXF1ZW50IG9yIGltcHJvcGVyIHVzYWdlIG9mIGxhbmRtYXJrcy9yZWdpb25zIGluIHBhZ2Vz
LiBPciBwZXJoYXBzIGJlY2F1c2Ugb3RoZXIgbWVjaGFuaXNtcyBhcmUgY29udGludWFsbHkgYmV0
dGVyLg0KaHR0cHM6Ly93ZWJhaW0ub3JnL3Byb2plY3RzL3NjcmVlbnJlYWRlcnN1cnZleTgvI2xh
bmRtYXJrczxodHRwczovL3dlYmFpbS5vcmcvcHJvamVjdHMvc2NyZWVucmVhZGVyc3VydmV5OC8j
bGFuZG1hcmtzPg0KQnJvd3NpbmcgYnkgaGVhZGluZ3MgaGFzIGEgaHVnZSBhY2NlcHRhbmNlIHRo
YW4gbGFuZG1hcmtzLg0KDQoNCk9uIFdlZCwgTWFyIDI0LCAyMDIxIGF0IDc6MDkgUE0gQW5kcmV3
cywgRGF2aWQgQiAoREVFRCkgPCBkYXZpZC5iLmFuZHJld3NAc3RhdGUubW4udXM8bWFpbHRvOmRh
dmlkLmIuYW5kcmV3c0BzdGF0ZS5tbi51cz4+IHdyb3RlOg0KDQo+IFRoaXMgc2l0ZSBkaWQgaGF2
ZSBhIGxvZyBvZiByZWdpb25zIQ0KPg0KPiBJIGRvbid0IGtub3cgd2hhdCBpdCBpcyBsaWtlIHZp
c3VhbGx5LCBidXQgd2hlbiB5b3UgYXJyb3cgdGhyb3VnaCwNCj4gdXNpbmcgSkFXUywgdmVyc3Vz
IHRhYmJpbmcgdGhyb3VnaCwgdGhleSBhcmUgcXVpdGUgZGlmZmVyZW50IGV4cGVyaWVuY2VzLg0K
Pg0KPiBEYXZlDQo+DQo+DQo+DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy
b206IFdlYkFJTS1Gb3J1bSA8d2ViYWltLWZvcnVtLWJvdW5jZXNAbGlzdC53ZWJhaW0ub3JnPG1h
aWx0bzp3ZWJhaW0tZm9ydW0tYm91bmNlc0BsaXN0LndlYmFpbS5vcmc+PiBPbiBCZWhhbGYgT2YN
Cj4gQmFydCBTaW1vbnMNCj4gU2VudDogV2VkbmVzZGF5LCBNYXJjaCAyNCwgMjAyMSA2OjE5IEFN
DQo+IFRvOiBXZWJBSU0gRGlzY3Vzc2lvbiBMaXN0IDx3ZWJhaW0tZm9ydW1AbGlzdC53ZWJhaW0u
b3JnPG1haWx0bzp3ZWJhaW0tZm9ydW1AbGlzdC53ZWJhaW0ub3JnPj4NCj4gU3ViamVjdDogUmU6
IFtXZWJBSU1dIFRoZSBpbXBvcnRhbmNlIG9mIGxhbmRtYXJrcyB0byBzY3JlZW4gcmVhZGVycz8N
Cj4NCj4gVGhpcyBtZXNzYWdlIG1heSBiZSBmcm9tIGFuIGV4dGVybmFsIGVtYWlsIHNvdXJjZS4N
Cj4gRG8gbm90IHNlbGVjdCBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB2ZXJpZmll
ZC4gUmVwb3J0IGFsbA0KPiBzdXNwaWNpb3VzIGVtYWlscyB0byBNaW5uZXNvdGEgSVQgU2Vydmlj
ZXMgU2VjdXJpdHkgT3BlcmF0aW9ucyBDZW50ZXIuDQo+DQo+IF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQo+DQo+ID4geW91IHNob3VsZCBhbHNvIHNwZWNpZnkgYW4gYXJpYS1sYWJl
bCBmb3IgdGhlIGxhbmRtYXJrLg0KPg0KPiBJIHdvdWxkIGxpa2UgdG8gYWRkIHNvbWUgbnVhbmNl
cyB0byB0aGlzIHN0YXRlbWVudC4NCj4gVGFraW5nIHRoZSB3ZWJzaXRlDQo+IGh0dHBzOi8vZ2Nj
MDIuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGd3d3
Lms8aHR0cHM6Ly9nY2MwMi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0
dHAlM0ElMkYlMkZ3d3cuaz4NCj4gZWF0LmdyL2luZGV4LnBocC9lbi88aHR0cDovL2VhdC5nci9p
bmRleC5waHAvZW4+ICZhbXA7ZGF0YT0wNCU3QzAxJTdDZGF2aWQuYi5hbmRyZXdzJTQwc3RhdGUu
DQo+IG1uLnVzJTdDMzNlMGRhYTFiMTE3NDUwNWFhZGUwOGQ4ZWViNjZjOTIlN0NlYjE0YjA0NjI0
YzQ0NTE5OGYyNmI4OWMyMTUNCj4gOTgyOGMlN0MwJTdDMSU3QzYzNzUyMTgxNDU4MDE1MTc3MSU3
Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNA0KPiB3TGpBd01EQWlMQ0pRSWpvaVYy
bHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZhbXA7c2RhDQo+IHRh
PVExT3RoWXpQOE5lOFQ5YiUyQjBoclZpZXF6b29VYyUyQk94MVBWTW9Kbk5laDFrJTNEJmFtcDty
ZXNlcnZlZD0wDQo+IGFzIGFuIGV4YW1wbGUuDQo+DQo+IFdoZW4gdXNpbmcgYSByb2xlPSJzZWFy
Y2giIHRoZXJlIGlzIHJlYWxseSBubyBuZWVkIHRvIGxhYmVsIHRoYXQNCj4gc2VjdGlvbiB3aXRo
IHRoZSB3b3JkIHNlYXJjaCB0aGF0IHlvdSBsYWJlbGxlZGJ5IGZyb20gYSB2aXN1YWxseSBoaWRk
ZW4gaGVhZGluZzoNCj4gPHNlY3Rpb24gcm9sZT0ic2VhcmNoIiBhcmlhLWxhYmVsbGVkYnk9Inpm
LS1zZWFyY2gtLXNlY3Rpb24taGVhZGluZyI+DQo+IDxoMiBpZD0iemYtLXNlYXJjaC0tc2VjdGlv
bi1oZWFkaW5nIiBjbGFzcz0iemYtLXNlY3Rpb24taGVhZGluZw0KPiB2aXN1YWxseS1oaWRkZW4i
PlNlYXJjaDwvaDI+DQo+DQo+IFdlIGFsc28gZG9uJ3QgbmVlZCBhIHNlY3Rpb24gbGFiZWxsZWQg
ImZvb3RlciIgaW5zaWRlIHRoZSA8Zm9vdGVyPiBlbGVtZW50Og0KPiA8Zm9vdGVyIHJvbGU9ImNv
bnRlbnRpbmZvIj4NCj4gPHNlY3Rpb24gYXJpYS1sYWJlbGxlZGJ5PSJ6Zi0tZm9vdGVyLWNvbnRl
bnQtLXNlY3Rpb24taGVhZGluZyINCj4gPGgyIGlkPSJ6Zi0tZm9vdGVyLWNvbnRlbnQtLXNlY3Rp
b24taGVhZGluZyINCj4gY2xhc3M9InZpc3VhbGx5LWhpZGRlbiI+Rm9vdGVyPC9oMj4NCj4NCj4g
RnVydGhlciBJJ2QgbGltaXQgdGhlIG51bWJlciBvZiBvY2N1cmVuY2VzIG9mIHRoZSBzYW1lIGxh
bmRtYXJrIG9uIGENCj4gcGFnZSByYXRoZXIgdGhhbiB0cnlpbmcgdG8gZmluZCBkZXNjcmlwdGl2
ZSBsYWJlbHMuIFRoZXkgY2xlYXJseSByYW4NCj4gb3V0IG9mIGluc3BpcmF0aW9uIHdoZW4gdGhl
eSBjYW1lIHVwIHdpdGggImNvbXBsZW1lbnRhcnkgY29udGVudCAobG93ZXIpIg0KPg0KPiBJdCBp
cyBub3QgdHJpdmlhbCB0byBsYWJlbCBhIHNldCBvZiBuYXYgc2VjdGlvbnMgaW4gYSB1c2VmdWwg
d2F5LiBNeQ0KPiBwbGVhIGlzIHRvIGxpbWl0IHRoZSBudW1iZXIgb2YgbGFuZG1hcmtzIGF2b2lk
aW5nIHRoZSBuZWNlc3NpdHkgdG8gbGFiZWwgdGhlbS4NCj4NCj4gUmVnYXJkcw0KPg0KPiBCYXJ0
IFNpbW9ucw0KPg0KPg0KPiBPcCAyMy8wMy8yMDIxIG9tIDIxOjMyIHNjaHJlZWYgZ2xlbiB3YWxr
ZXI6DQo+DQo+ID4gWW91IG9mdGVuIGZpbmQgc2Nhbm5pbmcgdG9vbHMgdGhhdCBmbGFnIGEgbGFj
ayBvZiBsYW5kbWFya3MgYXMgYW4gZXJyb3IuDQo+ID4gT3IgbW9yZSBmcmVxdWVudGx5LCB0aGV5
J3JlIG1hcmtlZCBhcyBhICJiZXN0IHByYWN0aWNlIiBidXQgbWFueQ0KPiA+IHBlb3BsZSBtaXNz
IHRoZSAiYmVzdCBwcmFjdGljZSIgcGFydCBhbmQgdGhpbmsgKmFsbCogZXJyb3JzIGZvdW5kIGJ5
DQo+ID4gdGhlIHRvb2wgYXJlIHJlcXVpcmVkIHRvIGJlIGZpeGVkLg0KPiA+DQo+ID4gTm90aGlu
ZyBpbiBXQ0FHIHJlcXVpcmVzIGxhbmRtYXJrcyBkaXJlY3RseS4gVGhleSBjYW4gYWJzb2x1dGVs
eSBiZQ0KPiA+IGhlbHBmdWwgZm9yIG5hdmlnYXRpbmcgdGhlIHBhZ2UgKHdpdGggYXNzaXN0aXZl
IHRlY2hub2xvZ3kpIGFuZA0KPiA+IGFpZGluZyBpbg0KPiA+IDIuNC4xIGNvbmZvcm1hbmNlLiBU
aGV5IGNhbiBhbHNvIGJlIGhlbHBmdWwgaW4gc2F0aXNmeWluZyAxLjMuMQ0KPiA+IHNpbmNlIHlv
dSBjYW4gb2Z0ZW4gdmlzdWFsbHkgZGlzY2VybiBhICJyZWxhdGlvbnNoaXAiIGFtb25nIGVsZW1l
bnRzDQo+ID4gdGhhdCBzaG91bGQgYmUgcHJvZ3JhbW1hdGljYWxseSBjb252ZXllZC4gQnV0IGl0
IGNhbiBiZSBhIGJpdA0KPiA+IHN1YmplY3RpdmUgb24gd2hldGhlciBsYW5kbWFya3MgYXJlIHJl
YWxseSAicmVxdWlyZWQiLg0KPiA+DQo+ID4gQnV0IGRvZXMgaXQgbWF0dGVyIGlmIHRoZXkgYXJl
IHRlY2huaWNhbGx5IG5lZWRlZCBvciBub3Q/IEZyb20gYSBVWA0KPiA+IHBlcnNwZWN0aXZlLCB0
aGV5J3JlIHN1cGVyIGhhbmR5IHNvIGdvIGFoZWFkIGFuZCBpbXBsZW1lbnQgdGhlbS4gSWYNCj4g
PiBicm93c2VycyB3b3VsZCBpbXBsZW1lbnQgYSBuYXRpdmUgd2F5IHRvIG5hdmlnYXRlIGJ5IGxh
bmRtYXJrcyB0aGVuDQo+ID4gbW9yZSB1c2VycyBjb3VsZCBiZW5lZml0IGZyb20gdGhlbSwgZXNw
ZWNpYWxseSBrZXlib2FyZCB1c2Vycy4NCj4gPg0KPiA+IEFuZCBpZiB5b3UgYXJlIGdvaW5nIHRv
IGltcGxlbWVudCB0aGVtLCBsZWFuIHRvd2FyZHMgdXNpbmcgbmF0aXZlDQo+ID4gc2VtYW50aWMg
aHRtbCBlbGVtZW50cyBmaXJzdCBiZWZvcmUgcmVseWluZyBvbiBBUklBIHJvbGVzLiBVc2UNCj4g
PiA8aGVhZGVyPiwgPGZvb3Rlcj4sIDxtYWluPiwgPG5hdj4sIDxzZWN0aW9uPiwgPGFzaWRlPiwg
ZXRjLiBBbmQNCj4gPiBvdGhlciB0aGFuIDxoZWFkZXI+LCA8Zm9vdGVyPiwgb3IgPG1haW4+LCB5
b3Ugc2hvdWxkIGFsc28gc3BlY2lmeSBhbg0KPiBhcmlhLWxhYmVsIGZvciB0aGUgbGFuZG1hcmsu
DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g
PiBUbyBtYW5hZ2UgeW91ciBzdWJzY3JpcHRpb24sIHZpc2l0DQo+ID4gaHR0cHM6Ly9nY2MwMi5z
YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkZsaXN0PGh0
dHBzOi8vZ2NjMDIuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNB
JTJGJTJGbGlzdD4uDQo+ID4gd2ViYWltLm9yZy88aHR0cDovL3dlYmFpbS5vcmc+ICZhbXA7ZGF0
YT0wNCU3QzAxJTdDZGF2aWQuYi5hbmRyZXdzJTQwc3RhdGUubW4udXMlN0MzM2UNCj4gPiAwZA0K
PiA+IGFhMWIxMTc0NTA1YWFkZTA4ZDhlZWI2NmM5MiU3Q2ViMTRiMDQ2MjRjNDQ1MTk4ZjI2Yjg5
YzIxNTk4MjhjJTdDMCU3DQo+ID4gQzENCj4gPiAlN0M2Mzc1MjE4MTQ1ODAxNTE3NzElN0NVbmtu
b3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQw0KPiA+IEpRDQo+ID4gSWpv
aVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZhbXA7c2RhdGE9
NkpseWV1bDYNCj4gPiAlMg0KPiA+IEZUekhPNU5Yc0hrNiUyRnJXWmp4ZFI5SGRCYWRhNWN2eXBU
aWslM0QmYW1wO3Jlc2VydmVkPTANCj4gPiBMaXN0IGFyY2hpdmVzIGF0DQo+ID4gaHR0cHM6Ly9n
Y2MwMi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkZ3
ZWI8aHR0cHM6Ly9nY2MwMi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0
dHAlM0ElMkYlMkZ3ZWI+DQo+ID4gYWkNCj4gPiBtLm9yZy9kaXNjdXNzaW9uL2FyY2hpdmVzPGh0
dHA6Ly9tLm9yZy9kaXNjdXNzaW9uL2FyY2hpdmVzPiAmYW1wO2RhdGE9MDQlN0MwMSU3Q2Rhdmlk
LmIuYW5kcmV3cyU0MHMNCj4gPiB0YQ0KPiA+IHRlLm1uLnVzJTdDMzNlMGRhYTFiMTE3NDUwNWFh
ZGUwOGQ4ZWViNjZjOTIlN0NlYjE0YjA0NjI0YzQ0NTE5OGYyNmI4DQo+ID4gOWMNCj4gPiAyMTU5
ODI4YyU3QzAlN0MxJTdDNjM3NTIxODE0NTgwMTYxNzI3JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNk
OGV5SldJag0KPiA+IG9pDQo+ID4gTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2
SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmYW0NCj4gPiBwOw0KPiA+IHNkYXRhPWJwZkhD
eHl6NFM5a3RIUlp4bWNYeldGRW9RNk9jVVRiSzJKb1NXNkkzeVUlM0QmYW1wO3Jlc2VydmVkPTAN
Cj4gPiBBZGRyZXNzIGxpc3QgbWVzc2FnZXMgdG8gd2ViYWltLWZvcnVtQGxpc3Qud2ViYWltLm9y
ZzxtYWlsdG86d2ViYWltLWZvcnVtQGxpc3Qud2ViYWltLm9yZz4NCj4NCj4NCj4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gVG8gbWFuYWdlIHlvdXIg
c3Vic2NyaXB0aW9uLCB2aXNpdA0KPiBodHRwczovL2djYzAyLnNhZmVsaW5rcy5wcm90ZWN0aW9u
Lm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRmxpc3Q8aHR0cHM6Ly9nY2MwMi5zYWZlbGlu
a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkZsaXN0Pi4NCj4gd2Vi
YWltLm9yZy88aHR0cDovL3dlYmFpbS5vcmcvPiAmYW1wO2RhdGE9MDQlN0MwMSU3Q2RhdmlkLmIu
YW5kcmV3cyU0MHN0YXRlLm1uLnVzJTdDMzNlMGQNCj4gYWExYjExNzQ1MDVhYWRlMDhkOGVlYjY2
YzkyJTdDZWIxNGIwNDYyNGM0NDUxOThmMjZiODljMjE1OTgyOGMlN0MwJTdDMQ0KPiAlN0M2Mzc1
MjE4MTQ1ODAxNjE3MjclN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01E
QWlMQ0pRDQo+IElqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMw
MDAmYW1wO3NkYXRhPXU1ZmpLQmMzS2sNCj4gUWhiM0dOTzlybmY0UmZUJTJCVmR6QzUlMkZaVUtQ
RGRJdlpUcyUzRCZhbXA7cmVzZXJ2ZWQ9MA0KPiBMaXN0IGFyY2hpdmVzIGF0DQo+IGh0dHBzOi8v
Z2NjMDIuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJG
d2ViYWk8aHR0cHM6Ly9nY2MwMi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs
PWh0dHAlM0ElMkYlMkZ3ZWJhaT4NCj4gbS5vcmcvZGlzY3Vzc2lvbi9hcmNoaXZlczxodHRwOi8v
bS5vcmcvZGlzY3Vzc2lvbi9hcmNoaXZlcz4gJmFtcDtkYXRhPTA0JTdDMDElN0NkYXZpZC5iLmFu
ZHJld3MlNDBzdGENCj4gdGUubW4udXMlN0MzM2UwZGFhMWIxMTc0NTA1YWFkZTA4ZDhlZWI2NmM5
MiU3Q2ViMTRiMDQ2MjRjNDQ1MTk4ZjI2Yjg5Yw0KPiAyMTU5ODI4YyU3QzAlN0MxJTdDNjM3NTIx
ODE0NTgwMTYxNzI3JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pDQo+IE1DNHdMakF3
TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAw
JmFtcDsNCj4gc2RhdGE9YnBmSEN4eXo0UzlrdEhSWnhtY1h6V0ZFb1E2T2NVVGJLMkpvU1c2STN5
VSUzRCZhbXA7cmVzZXJ2ZWQ9MA0KPiBBZGRyZXNzIGxpc3QgbWVzc2FnZXMgdG8gd2ViYWltLWZv
cnVtQGxpc3Qud2ViYWltLm9yZzxtYWlsdG86d2ViYWltLWZvcnVtQGxpc3Qud2ViYWltLm9yZz4N
Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gVG8g
bWFuYWdlIHlvdXIgc3Vic2NyaXB0aW9uLCB2aXNpdCBodHRwOi8vbGlzdC53ZWJhaW0ub3JnLzxo
dHRwOi8vbGlzdC53ZWJhaW0ub3JnPiBMaXN0DQo+IGFyY2hpdmVzIGF0IGh0dHA6Ly93ZWJhaW0u
b3JnL2Rpc2N1c3Npb24vYXJjaGl2ZXM8aHR0cDovL3dlYmFpbS5vcmcvZGlzY3Vzc2lvbi9hcmNo
aXZlcz4NCj4gQWRkcmVzcyBsaXN0IG1lc3NhZ2VzIHRvIHdlYmFpbS1mb3J1bUBsaXN0LndlYmFp
bS5vcmc8bWFpbHRvOndlYmFpbS1mb3J1bUBsaXN0LndlYmFpbS5vcmc+DQo+DQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVG8gbWFuYWdlIHlvdXIgc3Vi
c2NyaXB0aW9uLCB2aXNpdCBodHRwOi8vbGlzdC53ZWJhaW0ub3JnLzxodHRwOi8vbGlzdC53ZWJh
aW0ub3JnLz4gTGlzdCBhcmNoaXZlcyBhdCBodHRwOi8vd2ViYWltLm9yZy9kaXNjdXNzaW9uL2Fy
Y2hpdmVzPGh0dHA6Ly93ZWJhaW0ub3JnL2Rpc2N1c3Npb24vYXJjaGl2ZXM+DQpBZGRyZXNzIGxp
c3QgbWVzc2FnZXMgdG8gd2ViYWltLWZvcnVtQGxpc3Qud2ViYWltLm9yZzxtYWlsdG86d2ViYWlt
LWZvcnVtQGxpc3Qud2ViYWltLm9yZz4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQpUbyBtYW5hZ2UgeW91ciBzdWJzY3JpcHRpb24sIHZpc2l0IGh0dHA6
Ly9saXN0LndlYmFpbS5vcmcvPGh0dHA6Ly9saXN0LndlYmFpbS5vcmcvPg0KTGlzdCBhcmNoaXZl
cyBhdCBodHRwOi8vd2ViYWltLm9yZy9kaXNjdXNzaW9uL2FyY2hpdmVzPGh0dHA6Ly93ZWJhaW0u
b3JnL2Rpc2N1c3Npb24vYXJjaGl2ZXM+DQpBZGRyZXNzIGxpc3QgbWVzc2FnZXMgdG8gd2ViYWlt
LWZvcnVtQGxpc3Qud2ViYWltLm9yZzxtYWlsdG86d2ViYWltLWZvcnVtQGxpc3Qud2ViYWltLm9y
Zz4NCg==
--_005_DM6PR02MB5034A17865AC9EE69EE4465692629DM6PR02MB5034namp_
Content-Type: image/png; name="image003.png"
Content-Description: image003.png
Content-Disposition: inline; filename="image003.png"; size=212;
creation-date="Thu, 25 Mar 2021 13:30:46 GMT";
modification-date="Thu, 25 Mar 2021 13:30:46 GMT"
Content-ID: <image003.png@01D72151.27448AF0>
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAbAAAABRCAMAAACE/wOLAAAAAXNSR0ICQMB9xQAAAANQTFRFAAAA
p3o92gAAAAF0Uk5TAEDm2GYAAAAJcEhZcwAAEnQAABJ0Ad5mH3gAAAAZdEVYdFNvZnR3YXJlAE1p
Y3Jvc29mdCBPZmZpY2V/7TVxAAAAOElEQVR42u3BAQEAAACCIP+vbkhAAQAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAHcGiQEAAVO2oVUAAAAASUVORK5CYII=
--_005_DM6PR02MB5034A17865AC9EE69EE4465692629DM6PR02MB5034namp_
Content-Type: image/png; name="image004.png"
Content-Description: image004.png
Content-Disposition: inline; filename="image004.png"; size=190;
creation-date="Thu, 25 Mar 2021 13:30:46 GMT";
modification-date="Thu, 25 Mar 2021 13:30:46 GMT"
Content-ID: <image004.png@01D72151.27448AF0>
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAGwAAABsCAMAAAC4uKf/AAAAAXNSR0ICQMB9xQAAAANQTFRFAAAA
p3o92gAAAAF0Uk5TAEDm2GYAAAAJcEhZcwAAEnQAABJ0Ad5mH3gAAAAZdEVYdFNvZnR3YXJlAE1p
Y3Jvc29mdCBPZmZpY2V/7TVxAAAAIklEQVRo3u3BMQEAAADCoPVPbQ0PoAAAAAAAAAAAAAAAeDct
/AABKxOv+wAAAABJRU5ErkJggg==
--_005_DM6PR02MB5034A17865AC9EE69EE4465692629DM6PR02MB5034namp_--

From: Peter Weil
Date: Thu, Mar 25 2021 7:55AM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

One thing I wonder about landmarks is nesting. It's not uncommon to see a <nav> element tucked inside <main>. Is this really a good idea? My impression is that landmarks ought to kept at the top level unless there is a compelling reason (which does not include css or layout constraints) to do so.

It's also common is to see the heading (e.g., <h1>) for <main> to be located outside of <main>. How important is it to keep these together under the same landmark?

--
Peter Weil
Web Developer
University Marketing
University of Wisconsin–Madison


On 3/23/21, 3:08 PM, "WebAIM-Forum" < = EMAIL ADDRESS REMOVED = > wrote:


Hello,

My dev team and I are currently having a discussion about the importance of
landmarks in websites. I was under the impression that the guidance of WCAG
suggests that each webpage should have at least one or two landmarks per
page, to help give screenreader users the ability to understand the overall
layout of the page, for example that the page has at least the landmarks:

- a header (for overall site info such as website name)
- a nav (with links to different pages within the site or different
sections of the page if it's a page with a lot of different content such as
a long scroll type website)
- a main for the content of the page

We were working on a website that had a nav landmark that was by default
hidden as a landmark when the page loaded (in NVDA it was not showing as
anything under the Landmarks list in Elements List) and only became visible
as a landmark once a hamburger menu was opened.

I had flagged this as a WCAG failure, because the user has no way to know
the nav landmark is there until they open the nav by hamburger button (and
how can they open the nav when they don't know it's there? a sort of
catch-22 situation) and I had assumed that screenreader users would want
the nav landmark to be visible by default, either accessible by keyboard
shortcut or by the Landmarks list.

Have I given the nav landmark identity too much importance, that it must be
identified by the screenreader officially as a nav landmark by default when
the page loads? If the nav was clearly labelled for what it is (ie Main
menu) and clear instructions are given for opening the menu by the
hamburger icon, and otherwise is read out clearly by the screenreader and
navigable by keyboard, would that be considered sufficient for passing the
intent of WCAG's guidelines? Or do screen reader users first look at the
list of page landmarks to help them move quickly between different parts of
the page?


*x*
*Christine Hogenkamp (She, Her)*
Front-end Developer

CONTEXT CREATIVE
317 ADELAIDE ST. W., #500 | TORONTO, ON CANADA | M5V 1P9
<https://maps.google.com/?q17+ADELAIDE+ST.+W.,+%23500%C2%A0+%7C%C2%A0+TORONTO,+ON+CANADA%C2%A0+%7C%C2%A0+M5V+1P9&entry=gmail&source=g>

From: Christine Hogenkamp
Date: Thu, Mar 25 2021 2:44PM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

Thank you very much to everyone who has shared their wisdom on this
subject! I have shared all your remarks with my team for us to contemplate
and use as reference for our efforts to improve our development process for
better accessible websites.

I had completely forgotten about the WebAIM survey, that is an excellent
way to get an idea at a glance how often landmarks (and other elements) are
used, so thank you for the reminder and handy link!

Basically we are trying to figure out what is the best way to offer screen
reader users navigation tools within the site/page that caters
to screen reader users' expectations (as some have pointed out, if not many
sites bother to use landmarks, it makes sense a screen reader user wouldn't
bother to look for them) but also how they might wish a website was coded
to make their navigation easier - offer site code improvements where we
can. We don't want users to ever feel lost or that they are denied the
shortcuts they expect/want for moving quickly between sections or different
pages.

I'm usually the one tasked with assessing our efforts, testing our sites
with a mixture of automated checkers such as the ARCToolkit and aXe, but
also manual testing with NVDA and just looking at the code structure itself
for well-organized content. I've been slowly figuring out what
warnings/errors in checkers are false positives, but it definitely takes a
cognitive load of its own to figure out what errors can be safely ignored
but also what errors may not be caught at all by checkers since they are
more context-dependent.

We are definitely tackling better labelling for ARIA etc; one of my to-do's
that's ongoing is to get a better handle on the relationship between what a
screen reader announces and what we've coded/what is displayed in HTML on
the page. Sometimes this relationship is not as obvious as I might expect,
for example last week I learned that the use of aria-haspopup can prompt
the screen-reader to announce "submenu" - which makes sense, in retrospect
but when the code has a lot of elements and attributes going on, it can
sometimes be tricky to tease out which aspect is causing the particular
announcement.

Thanks again!

*x*
*Christine Hogenkamp (She, Her)*
Front-end Developer

CONTEXT CREATIVE
317 ADELAIDE ST. W., #500 | TORONTO, ON CANADA | M5V 1P9
<https://maps.google.com/?q17+ADELAIDE+ST.+W.,+%23500%C2%A0+%7C%C2%A0+TORONTO,+ON+CANADA%C2%A0+%7C%C2%A0+M5V+1P9&entry=gmail&source=g>

>
>

From: David Engebretson Jr.
Date: Thu, Mar 25 2021 4:15PM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

I'm happy to jabber off-list if you want me to share our design system with you and your team.

Our designers and web engineers have done an amazing job building in accessibility to our components.

My personal email is this one (accessible dot engineering at gmail.com). Feel free to contact me there and I'll point you in a couple of directions that I've found super helpful to reduce systemic accessibility issues.

Best,
David


-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Christine Hogenkamp
Sent: Thursday, March 25, 2021 1:44 PM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] The importance of landmarks to screen readers?

Thank you very much to everyone who has shared their wisdom on this subject! I have shared all your remarks with my team for us to contemplate and use as reference for our efforts to improve our development process for better accessible websites.

I had completely forgotten about the WebAIM survey, that is an excellent way to get an idea at a glance how often landmarks (and other elements) are used, so thank you for the reminder and handy link!

Basically we are trying to figure out what is the best way to offer screen reader users navigation tools within the site/page that caters to screen reader users' expectations (as some have pointed out, if not many sites bother to use landmarks, it makes sense a screen reader user wouldn't bother to look for them) but also how they might wish a website was coded to make their navigation easier - offer site code improvements where we can. We don't want users to ever feel lost or that they are denied the shortcuts they expect/want for moving quickly between sections or different pages.

I'm usually the one tasked with assessing our efforts, testing our sites with a mixture of automated checkers such as the ARCToolkit and aXe, but also manual testing with NVDA and just looking at the code structure itself for well-organized content. I've been slowly figuring out what warnings/errors in checkers are false positives, but it definitely takes a cognitive load of its own to figure out what errors can be safely ignored but also what errors may not be caught at all by checkers since they are more context-dependent.

We are definitely tackling better labelling for ARIA etc; one of my to-do's that's ongoing is to get a better handle on the relationship between what a screen reader announces and what we've coded/what is displayed in HTML on the page. Sometimes this relationship is not as obvious as I might expect, for example last week I learned that the use of aria-haspopup can prompt the screen-reader to announce "submenu" - which makes sense, in retrospect but when the code has a lot of elements and attributes going on, it can sometimes be tricky to tease out which aspect is causing the particular announcement.

Thanks again!

*x*
*Christine Hogenkamp (She, Her)*
Front-end Developer

CONTEXT CREATIVE
317 ADELAIDE ST. W., #500 | TORONTO, ON CANADA | M5V 1P9 <https://maps.google.com/?q17+ADELAIDE+ST.+W.,+%23500%C2%A0+%7C%C2%A0+TORONTO,+ON+CANADA%C2%A0+%7C%C2%A0+M5V+1P9&entry=gmail&source=g>

>
>

From: Birkir R. Gunnarsson
Date: Thu, Mar 25 2021 7:56PM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

One of the explanations for the decreased landmark usage comes down to
the screen readers themselves.
Jaws has made landmarks practically a hidden feature in recent
versions, you actually have to change the default settings to see them
in browse mode.
I find that perplexing to say the least.
Part ofit could be overuse or misuse of landmarks, which is why I
personally go after the big 3 but try to cut down on other landmark
use, because each landmark region adds verbiage and people don't have
time to listen to unnecessary screen reader chatter, the landmarks can
only be used when they provide value.
Landmarks and headings serve different purposes and should be used together.
Landmarks tell you about fixed regions of the page, headings tell you
about the organizations of the page content.
When used together they give a complete and informative picture of the
page, but if one is used without the other or if one is misused they
provide confusing, overly verbose, or incomplete info.



On 3/25/21, Peter Weil < = EMAIL ADDRESS REMOVED = > wrote:
> One thing I wonder about landmarks is nesting. It's not uncommon to see a
> <nav> element tucked inside <main>. Is this really a good idea? My
> impression is that landmarks ought to kept at the top level unless there is
> a compelling reason (which does not include css or layout constraints) to do
> so.
>
> It's also common is to see the heading (e.g., <h1>) for <main> to be located
> outside of <main>. How important is it to keep these together under the same
> landmark?
>
> --
> Peter Weil
> Web Developer
> University Marketing
> University of Wisconsin–Madison
>
>
> On 3/23/21, 3:08 PM, "WebAIM-Forum" < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>
> Hello,
>
> My dev team and I are currently having a discussion about the importance of
> landmarks in websites. I was under the impression that the guidance of WCAG
> suggests that each webpage should have at least one or two landmarks per
> page, to help give screenreader users the ability to understand the overall
> layout of the page, for example that the page has at least the landmarks:
>
> - a header (for overall site info such as website name)
> - a nav (with links to different pages within the site or different
> sections of the page if it's a page with a lot of different content such as
> a long scroll type website)
> - a main for the content of the page
>
> We were working on a website that had a nav landmark that was by default
> hidden as a landmark when the page loaded (in NVDA it was not showing as
> anything under the Landmarks list in Elements List) and only became visible
> as a landmark once a hamburger menu was opened.
>
> I had flagged this as a WCAG failure, because the user has no way to know
> the nav landmark is there until they open the nav by hamburger button (and
> how can they open the nav when they don't know it's there? a sort of
> catch-22 situation) and I had assumed that screenreader users would want
> the nav landmark to be visible by default, either accessible by keyboard
> shortcut or by the Landmarks list.
>
> Have I given the nav landmark identity too much importance, that it must be
> identified by the screenreader officially as a nav landmark by default when
> the page loads? If the nav was clearly labelled for what it is (ie Main
> menu) and clear instructions are given for opening the menu by the
> hamburger icon, and otherwise is read out clearly by the screenreader and
> navigable by keyboard, would that be considered sufficient for passing the
> intent of WCAG's guidelines? Or do screen reader users first look at the
> list of page landmarks to help them move quickly between different parts of
> the page?
>
>
> *x*
> *Christine Hogenkamp (She, Her)*
> Front-end Developer
>
> CONTEXT CREATIVE
> 317 ADELAIDE ST. W., #500 | TORONTO, ON CANADA | M5V 1P9
> <https://maps.google.com/?q17+ADELAIDE+ST.+W.,+%23500%C2%A0+%7C%C2%A0+TORONTO,+ON+CANADA%C2%A0+%7C%C2%A0+M5V+1P9&entry=gmail&source=g>
> > > > > > > > >


--
Work hard. Have fun. Make history.

From: Bart Simons
Date: Sun, Mar 28 2021 8:34AM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

Hello,

For me there is no problem to nest landmarks. It is common to see a
<nav> inside the <header>. It could happen that a <nav> is part of the
<main>. E.g. a section with liks to related articles, pagination links ...

<h1> outside of <main> is a failure for me, since <h1> is undoubtedly
part of the main content of a web page.

An interesting debate is whether breadcrumbs should be part of <main>?

Regards
Bart

Op 25/03/2021 om 14:55 schreef Peter Weil:
> One thing I wonder about landmarks is nesting. It's not uncommon to see a <nav> element tucked inside <main>. Is this really a good idea? My impression is that landmarks ought to kept at the top level unless there is a compelling reason (which does not include css or layout constraints) to do so.
>
> It's also common is to see the heading (e.g., <h1>) for <main> to be located outside of <main>. How important is it to keep these together under the same landmark?
>
> --
> Peter Weil
> Web Developer
> University Marketing
> University of Wisconsin–Madison
>
>
> On 3/23/21, 3:08 PM, "WebAIM-Forum" < = EMAIL ADDRESS REMOVED = > wrote:
>
>
> Hello,
>
> My dev team and I are currently having a discussion about the importance of
> landmarks in websites. I was under the impression that the guidance of WCAG
> suggests that each webpage should have at least one or two landmarks per
> page, to help give screenreader users the ability to understand the overall
> layout of the page, for example that the page has at least the landmarks:
>
> - a header (for overall site info such as website name)
> - a nav (with links to different pages within the site or different
> sections of the page if it's a page with a lot of different content such as
> a long scroll type website)
> - a main for the content of the page
>
> We were working on a website that had a nav landmark that was by default
> hidden as a landmark when the page loaded (in NVDA it was not showing as
> anything under the Landmarks list in Elements List) and only became visible
> as a landmark once a hamburger menu was opened.
>
> I had flagged this as a WCAG failure, because the user has no way to know
> the nav landmark is there until they open the nav by hamburger button (and
> how can they open the nav when they don't know it's there? a sort of
> catch-22 situation) and I had assumed that screenreader users would want
> the nav landmark to be visible by default, either accessible by keyboard
> shortcut or by the Landmarks list.
>
> Have I given the nav landmark identity too much importance, that it must be
> identified by the screenreader officially as a nav landmark by default when
> the page loads? If the nav was clearly labelled for what it is (ie Main
> menu) and clear instructions are given for opening the menu by the
> hamburger icon, and otherwise is read out clearly by the screenreader and
> navigable by keyboard, would that be considered sufficient for passing the
> intent of WCAG's guidelines? Or do screen reader users first look at the
> list of page landmarks to help them move quickly between different parts of
> the page?
>
>
> *x*
> *Christine Hogenkamp (She, Her)*
> Front-end Developer
>
> CONTEXT CREATIVE
> 317 ADELAIDE ST. W., #500 | TORONTO, ON CANADA | M5V 1P9
> <https://maps.google.com/?q17+ADELAIDE+ST.+W.,+%23500%C2%A0+%7C%C2%A0+TORONTO,+ON+CANADA%C2%A0+%7C%C2%A0+M5V+1P9&entry=gmail&source=g>
> > > > > > > >

From: Birkir R. Gunnarsson
Date: Sun, Mar 28 2021 9:13AM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

I agree. I do not see how nesting a complementary landmark inside the
main landmark is an ARIA violation.

The argument goes that the complementary landmark contains content
that is independent of the rest of the page. Therefore that content
clearly doesn't belong in the main content of the page, which is the
content unique to the page.
It does make sense to a certain extent but it has to be balanced
against context and discoverability.
Say you have a hotel website that displays a widget with up-to-date
weather information for the hotel location.
I would put that in a complementary landmark (if I were to use any landmark).
So from the nesting perspcetive that landmark shoud be put ouside the
main landmark but if you put it above the main landmark it might not
be easily dicoverable.
If you put it below the main landmark (between main and footer) it
probably would work but might not correspond to the visual order of
the page.
In a nice tropical setting you probably want to put the weather info
in a prime location, adjacent to the reservation area.
You'd want that info to be just as prominent to someone who doesn't
see the page or someone uses an alternative content order.
So if you can't ntest complementary inside main you have to choose
between not using a landmark for this info or manipulating the content
order to push it outside the main content, also making it less
discoverable or relevant if you don't see the page.
Ultimately, a landmark is supposed to aid accessibility. I think this
rule actually can do the opposite, which either makes the
complementary landmark not a good landmark or it needs to be revised.
Cheers
-B

On 3/28/21, Bart Simons < = EMAIL ADDRESS REMOVED = > wrote:
> Hello,
>
> For me there is no problem to nest landmarks. It is common to see a
> <nav> inside the <header>. It could happen that a <nav> is part of the
> <main>. E.g. a section with liks to related articles, pagination links ...
>
> <h1> outside of <main> is a failure for me, since <h1> is undoubtedly
> part of the main content of a web page.
>
> An interesting debate is whether breadcrumbs should be part of <main>?
>
> Regards
> Bart
>
> Op 25/03/2021 om 14:55 schreef Peter Weil:
>> One thing I wonder about landmarks is nesting. It's not uncommon to see a
>> <nav> element tucked inside <main>. Is this really a good idea? My
>> impression is that landmarks ought to kept at the top level unless there
>> is a compelling reason (which does not include css or layout constraints)
>> to do so.
>>
>> It's also common is to see the heading (e.g., <h1>) for <main> to be
>> located outside of <main>. How important is it to keep these together
>> under the same landmark?
>>
>> --
>> Peter Weil
>> Web Developer
>> University Marketing
>> University of Wisconsin–Madison
>>
>>
>> On 3/23/21, 3:08 PM, "WebAIM-Forum" < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>>
>> Hello,
>>
>> My dev team and I are currently having a discussion about the importance
>> of
>> landmarks in websites. I was under the impression that the guidance of
>> WCAG
>> suggests that each webpage should have at least one or two landmarks per
>> page, to help give screenreader users the ability to understand the
>> overall
>> layout of the page, for example that the page has at least the landmarks:
>>
>> - a header (for overall site info such as website name)
>> - a nav (with links to different pages within the site or different
>> sections of the page if it's a page with a lot of different content such
>> as
>> a long scroll type website)
>> - a main for the content of the page
>>
>> We were working on a website that had a nav landmark that was by default
>> hidden as a landmark when the page loaded (in NVDA it was not showing as
>> anything under the Landmarks list in Elements List) and only became
>> visible
>> as a landmark once a hamburger menu was opened.
>>
>> I had flagged this as a WCAG failure, because the user has no way to know
>> the nav landmark is there until they open the nav by hamburger button (and
>> how can they open the nav when they don't know it's there? a sort of
>> catch-22 situation) and I had assumed that screenreader users would want
>> the nav landmark to be visible by default, either accessible by keyboard
>> shortcut or by the Landmarks list.
>>
>> Have I given the nav landmark identity too much importance, that it must
>> be
>> identified by the screenreader officially as a nav landmark by default
>> when
>> the page loads? If the nav was clearly labelled for what it is (ie Main
>> menu) and clear instructions are given for opening the menu by the
>> hamburger icon, and otherwise is read out clearly by the screenreader and
>> navigable by keyboard, would that be considered sufficient for passing the
>> intent of WCAG's guidelines? Or do screen reader users first look at the
>> list of page landmarks to help them move quickly between different parts
>> of
>> the page?
>>
>>
>> *x*
>> *Christine Hogenkamp (She, Her)*
>> Front-end Developer
>>
>> CONTEXT CREATIVE
>> 317 ADELAIDE ST. W., #500 | TORONTO, ON CANADA | M5V 1P9
>> <https://maps.google.com/?q17+ADELAIDE+ST.+W.,+%23500%C2%A0+%7C%C2%A0+TORONTO,+ON+CANADA%C2%A0+%7C%C2%A0+M5V+1P9&entry=gmail&source=g>
>> >> >> >> >> >> >> >> >
>
> > > > >


--
Work hard. Have fun. Make history.

From: Steve Green
Date: Sun, Mar 28 2021 8:21PM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

According to the specification, nesting a complementary landmark inside the main landmark is an ARIA violation because complementary landmarks should be top level landmarks (i.e. not contained within any other landmarks).

https://www.w3.org/TR/wai-aria-1.1/#complementary

https://www.w3.org/TR/wai-aria-practices/examples/landmarks/complementary.html

Steve Green
Managing Director
Test Partners Ltd


-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Birkir R. Gunnarsson
Sent: 28 March 2021 16:14
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] The importance of landmarks to screen readers?

I agree. I do not see how nesting a complementary landmark inside the main landmark is an ARIA violation.

The argument goes that the complementary landmark contains content that is independent of the rest of the page. Therefore that content clearly doesn't belong in the main content of the page, which is the content unique to the page.
It does make sense to a certain extent but it has to be balanced against context and discoverability.
Say you have a hotel website that displays a widget with up-to-date weather information for the hotel location.
I would put that in a complementary landmark (if I were to use any landmark).
So from the nesting perspcetive that landmark shoud be put ouside the main landmark but if you put it above the main landmark it might not be easily dicoverable.
If you put it below the main landmark (between main and footer) it probably would work but might not correspond to the visual order of the page.
In a nice tropical setting you probably want to put the weather info in a prime location, adjacent to the reservation area.
You'd want that info to be just as prominent to someone who doesn't see the page or someone uses an alternative content order.
So if you can't ntest complementary inside main you have to choose between not using a landmark for this info or manipulating the content order to push it outside the main content, also making it less discoverable or relevant if you don't see the page.
Ultimately, a landmark is supposed to aid accessibility. I think this rule actually can do the opposite, which either makes the complementary landmark not a good landmark or it needs to be revised.
Cheers
-B

On 3/28/21, Bart Simons < = EMAIL ADDRESS REMOVED = > wrote:
> Hello,
>
> For me there is no problem to nest landmarks. It is common to see a
> <nav> inside the <header>. It could happen that a <nav> is part of the
> <main>. E.g. a section with liks to related articles, pagination links ...
>
> <h1> outside of <main> is a failure for me, since <h1> is undoubtedly
> part of the main content of a web page.
>
> An interesting debate is whether breadcrumbs should be part of <main>?
>
> Regards
> Bart
>
> Op 25/03/2021 om 14:55 schreef Peter Weil:
>> One thing I wonder about landmarks is nesting. It's not uncommon to
>> see a <nav> element tucked inside <main>. Is this really a good idea?
>> My impression is that landmarks ought to kept at the top level unless
>> there is a compelling reason (which does not include css or layout
>> constraints) to do so.
>>
>> It's also common is to see the heading (e.g., <h1>) for <main> to be
>> located outside of <main>. How important is it to keep these together
>> under the same landmark?
>>
>> --
>> Peter Weil
>> Web Developer
>> University Marketing
>> University of Wisconsin–Madison
>>
>>
>> On 3/23/21, 3:08 PM, "WebAIM-Forum"
>> < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>>
>> Hello,
>>
>> My dev team and I are currently having a discussion about the
>> importance of landmarks in websites. I was under the impression that
>> the guidance of WCAG suggests that each webpage should have at least
>> one or two landmarks per page, to help give screenreader users the
>> ability to understand the overall layout of the page, for example
>> that the page has at least the landmarks:
>>
>> - a header (for overall site info such as website name)
>> - a nav (with links to different pages within the site or different
>> sections of the page if it's a page with a lot of different content
>> such as a long scroll type website)
>> - a main for the content of the page
>>
>> We were working on a website that had a nav landmark that was by
>> default hidden as a landmark when the page loaded (in NVDA it was not
>> showing as anything under the Landmarks list in Elements List) and
>> only became visible as a landmark once a hamburger menu was opened.
>>
>> I had flagged this as a WCAG failure, because the user has no way to
>> know the nav landmark is there until they open the nav by hamburger
>> button (and how can they open the nav when they don't know it's
>> there? a sort of
>> catch-22 situation) and I had assumed that screenreader users would
>> want the nav landmark to be visible by default, either accessible by
>> keyboard shortcut or by the Landmarks list.
>>
>> Have I given the nav landmark identity too much importance, that it
>> must be identified by the screenreader officially as a nav landmark
>> by default when the page loads? If the nav was clearly labelled for
>> what it is (ie Main
>> menu) and clear instructions are given for opening the menu by the
>> hamburger icon, and otherwise is read out clearly by the screenreader
>> and navigable by keyboard, would that be considered sufficient for
>> passing the intent of WCAG's guidelines? Or do screen reader users
>> first look at the list of page landmarks to help them move quickly
>> between different parts of the page?
>>
>>
>> *x*
>> *Christine Hogenkamp (She, Her)*
>> Front-end Developer
>>
>> CONTEXT CREATIVE
>> 317 ADELAIDE ST. W., #500 | TORONTO, ON CANADA | M5V 1P9
>> <https://maps.google.com/?q17+ADELAIDE+ST.+W.,+%23500%C2%A0+%7C%C2%
>> A0+TORONTO,+ON+CANADA%C2%A0+%7C%C2%A0+M5V+1P9&entry=gmail&source=g>
>> >> >> archives at http://webaim.org/discussion/archives
>> >> >> >> archives at http://webaim.org/discussion/archives
>> >
>
> > > archives at http://webaim.org/discussion/archives
> >


--
Work hard. Have fun. Make history.

From: Jonathan Avila
Date: Sun, Mar 28 2021 8:34PM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

> According to the specification, nesting a complementary landmark inside the main landmark is an ARIA violation because complementary landmarks should be top level landmarks (i.e. not contained within any other landmarks).

I've always found this information about complementary interesting because an aside has different allowances but is the most closely matching landmark.

Jonathan

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Steve Green
Sent: Sunday, March 28, 2021 10:21 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] The importance of landmarks to screen readers?

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


According to the specification, nesting a complementary landmark inside the main landmark is an ARIA violation because complementary landmarks should be top level landmarks (i.e. not contained within any other landmarks).

https://www.w3.org/TR/wai-aria-1.1/#complementary

https://www.w3.org/TR/wai-aria-practices/examples/landmarks/complementary.html

Steve Green
Managing Director
Test Partners Ltd


-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Birkir R. Gunnarsson
Sent: 28 March 2021 16:14
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] The importance of landmarks to screen readers?

I agree. I do not see how nesting a complementary landmark inside the main landmark is an ARIA violation.

The argument goes that the complementary landmark contains content that is independent of the rest of the page. Therefore that content clearly doesn't belong in the main content of the page, which is the content unique to the page.
It does make sense to a certain extent but it has to be balanced against context and discoverability.
Say you have a hotel website that displays a widget with up-to-date weather information for the hotel location.
I would put that in a complementary landmark (if I were to use any landmark).
So from the nesting perspcetive that landmark shoud be put ouside the main landmark but if you put it above the main landmark it might not be easily dicoverable.
If you put it below the main landmark (between main and footer) it probably would work but might not correspond to the visual order of the page.
In a nice tropical setting you probably want to put the weather info in a prime location, adjacent to the reservation area.
You'd want that info to be just as prominent to someone who doesn't see the page or someone uses an alternative content order.
So if you can't ntest complementary inside main you have to choose between not using a landmark for this info or manipulating the content order to push it outside the main content, also making it less discoverable or relevant if you don't see the page.
Ultimately, a landmark is supposed to aid accessibility. I think this rule actually can do the opposite, which either makes the complementary landmark not a good landmark or it needs to be revised.
Cheers
-B

On 3/28/21, Bart Simons < = EMAIL ADDRESS REMOVED = > wrote:
> Hello,
>
> For me there is no problem to nest landmarks. It is common to see a
> <nav> inside the <header>. It could happen that a <nav> is part of the
> <main>. E.g. a section with liks to related articles, pagination links ...
>
> <h1> outside of <main> is a failure for me, since <h1> is undoubtedly
> part of the main content of a web page.
>
> An interesting debate is whether breadcrumbs should be part of <main>?
>
> Regards
> Bart
>
> Op 25/03/2021 om 14:55 schreef Peter Weil:
>> One thing I wonder about landmarks is nesting. It's not uncommon to
>> see a <nav> element tucked inside <main>. Is this really a good idea?
>> My impression is that landmarks ought to kept at the top level unless
>> there is a compelling reason (which does not include css or layout
>> constraints) to do so.
>>
>> It's also common is to see the heading (e.g., <h1>) for <main> to be
>> located outside of <main>. How important is it to keep these together
>> under the same landmark?
>>
>> --
>> Peter Weil
>> Web Developer
>> University Marketing
>> University of Wisconsin–Madison
>>
>>
>> On 3/23/21, 3:08 PM, "WebAIM-Forum"
>> < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>>
>> Hello,
>>
>> My dev team and I are currently having a discussion about the
>> importance of landmarks in websites. I was under the impression that
>> the guidance of WCAG suggests that each webpage should have at least
>> one or two landmarks per page, to help give screenreader users the
>> ability to understand the overall layout of the page, for example
>> that the page has at least the landmarks:
>>
>> - a header (for overall site info such as website name)
>> - a nav (with links to different pages within the site or different
>> sections of the page if it's a page with a lot of different content
>> such as a long scroll type website)
>> - a main for the content of the page
>>
>> We were working on a website that had a nav landmark that was by
>> default hidden as a landmark when the page loaded (in NVDA it was not
>> showing as anything under the Landmarks list in Elements List) and
>> only became visible as a landmark once a hamburger menu was opened.
>>
>> I had flagged this as a WCAG failure, because the user has no way to
>> know the nav landmark is there until they open the nav by hamburger
>> button (and how can they open the nav when they don't know it's
>> there? a sort of
>> catch-22 situation) and I had assumed that screenreader users would
>> want the nav landmark to be visible by default, either accessible by
>> keyboard shortcut or by the Landmarks list.
>>
>> Have I given the nav landmark identity too much importance, that it
>> must be identified by the screenreader officially as a nav landmark
>> by default when the page loads? If the nav was clearly labelled for
>> what it is (ie Main
>> menu) and clear instructions are given for opening the menu by the
>> hamburger icon, and otherwise is read out clearly by the screenreader
>> and navigable by keyboard, would that be considered sufficient for
>> passing the intent of WCAG's guidelines? Or do screen reader users
>> first look at the list of page landmarks to help them move quickly
>> between different parts of the page?
>>
>>
>> *x*
>> *Christine Hogenkamp (She, Her)*
>> Front-end Developer
>>
>> CONTEXT CREATIVE
>> 317 ADELAIDE ST. W., #500 | TORONTO, ON CANADA | M5V 1P9
>> <https://maps.google.com/?q17+ADELAIDE+ST.+W.,+%23500%C2%A0+%7C%C2%
>> A0+TORONTO,+ON+CANADA%C2%A0+%7C%C2%A0+M5V+1P9&entry=gmail&source=g>
>> >> >> archives at http://webaim.org/discussion/archives
>> >> >> >> archives at http://webaim.org/discussion/archives
>> >
>
> > > archives at http://webaim.org/discussion/archives
> >


--
Work hard. Have fun. Make history.

From: Peter Weil
Date: Mon, Mar 29 2021 6:53AM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

Yes, the ARIA spec is quite clear about this. And while it does mention that nesting is permissible, examples are few and the implication (as I read it) is that these are probably limited to cases where there are multiple elements with such roles as application, document, and perhaps article(?). I think these kinds of cases are relatively rare, at least in my experience.

As a developer. I work with all kinds of layout designs that do not take landmarks into account and unwittingly imply nested landmarks (that's another discussion), and it can be a challenge to adapt them to a landmarked-based structure. This is the main reason I asked my question.

Regarding discoverability, I'd like to hear more about how or why content within, say, an aside, might be less discoverable if it were at the top level as opposed to be nested. In many cases, visual order or organization is flexible enough via CSS to achieve to decent balance between page structure and visual presentation. Regardless, if faced with a situation where visual design interfered with page structure (i.e., correct landmark usage), I might request more presentation flexibility for accessibility reasons.

Peter

--
Peter Weil
Web Developer
University Marketing
University of Wisconsin–Madison



On 3/28/21, 9:21 PM, "WebAIM-Forum" < = EMAIL ADDRESS REMOVED = > wrote:


According to the specification, nesting a complementary landmark inside the main landmark is an ARIA violation because complementary landmarks should be top level landmarks (i.e. not contained within any other landmarks).

https://www.w3.org/TR/wai-aria-1.1/#complementary

https://www.w3.org/TR/wai-aria-practices/examples/landmarks/complementary.html

Steve Green
Managing Director
Test Partners Ltd


-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Birkir R. Gunnarsson
Sent: 28 March 2021 16:14
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] The importance of landmarks to screen readers?

I agree. I do not see how nesting a complementary landmark inside the main landmark is an ARIA violation.

The argument goes that the complementary landmark contains content that is independent of the rest of the page. Therefore that content clearly doesn't belong in the main content of the page, which is the content unique to the page.
It does make sense to a certain extent but it has to be balanced against context and discoverability.
Say you have a hotel website that displays a widget with up-to-date weather information for the hotel location.
I would put that in a complementary landmark (if I were to use any landmark).
So from the nesting perspcetive that landmark shoud be put ouside the main landmark but if you put it above the main landmark it might not be easily dicoverable.
If you put it below the main landmark (between main and footer) it probably would work but might not correspond to the visual order of the page.
In a nice tropical setting you probably want to put the weather info in a prime location, adjacent to the reservation area.
You'd want that info to be just as prominent to someone who doesn't see the page or someone uses an alternative content order.
So if you can't ntest complementary inside main you have to choose between not using a landmark for this info or manipulating the content order to push it outside the main content, also making it less discoverable or relevant if you don't see the page.
Ultimately, a landmark is supposed to aid accessibility. I think this rule actually can do the opposite, which either makes the complementary landmark not a good landmark or it needs to be revised.
Cheers
-B

On 3/28/21, Bart Simons < = EMAIL ADDRESS REMOVED = > wrote:
> Hello,
>
> For me there is no problem to nest landmarks. It is common to see a
> <nav> inside the <header>. It could happen that a <nav> is part of the
> <main>. E.g. a section with liks to related articles, pagination links ...
>
> <h1> outside of <main> is a failure for me, since <h1> is undoubtedly
> part of the main content of a web page.
>
> An interesting debate is whether breadcrumbs should be part of <main>?
>
> Regards
> Bart
>
> Op 25/03/2021 om 14:55 schreef Peter Weil:
>> One thing I wonder about landmarks is nesting. It's not uncommon to
>> see a <nav> element tucked inside <main>. Is this really a good idea?
>> My impression is that landmarks ought to kept at the top level unless
>> there is a compelling reason (which does not include css or layout
>> constraints) to do so.
>>
>> It's also common is to see the heading (e.g., <h1>) for <main> to be
>> located outside of <main>. How important is it to keep these together
>> under the same landmark?
>>
>> --
>> Peter Weil
>> Web Developer
>> University Marketing
>> University of Wisconsin–Madison
>>
>>
>> On 3/23/21, 3:08 PM, "WebAIM-Forum"
>> < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>>
>> Hello,
>>
>> My dev team and I are currently having a discussion about the
>> importance of landmarks in websites. I was under the impression that
>> the guidance of WCAG suggests that each webpage should have at least
>> one or two landmarks per page, to help give screenreader users the
>> ability to understand the overall layout of the page, for example
>> that the page has at least the landmarks:
>>
>> - a header (for overall site info such as website name)
>> - a nav (with links to different pages within the site or different
>> sections of the page if it's a page with a lot of different content
>> such as a long scroll type website)
>> - a main for the content of the page
>>
>> We were working on a website that had a nav landmark that was by
>> default hidden as a landmark when the page loaded (in NVDA it was not
>> showing as anything under the Landmarks list in Elements List) and
>> only became visible as a landmark once a hamburger menu was opened.
>>
>> I had flagged this as a WCAG failure, because the user has no way to
>> know the nav landmark is there until they open the nav by hamburger
>> button (and how can they open the nav when they don't know it's
>> there? a sort of
>> catch-22 situation) and I had assumed that screenreader users would
>> want the nav landmark to be visible by default, either accessible by
>> keyboard shortcut or by the Landmarks list.
>>
>> Have I given the nav landmark identity too much importance, that it
>> must be identified by the screenreader officially as a nav landmark
>> by default when the page loads? If the nav was clearly labelled for
>> what it is (ie Main
>> menu) and clear instructions are given for opening the menu by the
>> hamburger icon, and otherwise is read out clearly by the screenreader
>> and navigable by keyboard, would that be considered sufficient for
>> passing the intent of WCAG's guidelines? Or do screen reader users
>> first look at the list of page landmarks to help them move quickly
>> between different parts of the page?
>>
>>
>> *x*
>> *Christine Hogenkamp (She, Her)*
>> Front-end Developer
>>
>> CONTEXT CREATIVE
>> 317 ADELAIDE ST. W., #500 | TORONTO, ON CANADA | M5V 1P9
>> <https://maps.google.com/?q17+ADELAIDE+ST.+W.,+%23500%C2%A0+%7C%C2%
>> A0+TORONTO,+ON+CANADA%C2%A0+%7C%C2%A0+M5V+1P9&entry=gmail&source=g>
>> >> >> archives at http://webaim.org/discussion/archives
>> >> >> >> archives at http://webaim.org/discussion/archives
>> >
>
> > > archives at http://webaim.org/discussion/archives
> >


--
Work hard. Have fun. Make history.

From: Birkir R. Gunnarsson
Date: Mon, Mar 29 2021 8:24AM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

Peter

Many users, mysefl included, only review the header of a website once,
then use the main content landmark, the h1 heading at the start of the
main content (if site is well implemented) or use the skip link to
jump straight to the main content of a page and explore from there.
If you place a complementary content prior to the main content, e.g.
an alert or special announcement, a user who does not see the page and
uses a methodology that involves jumping to the main content, will not
notice it.
If you, however, place this content right after the h1 heading inside
the main content, users who use this methodology will spot it.
Since, in my line of business, we use complementary content primarily
for special announcements or alerts (like closures or similar) we
don't want users to miss them.
Yes, there are other ways to announce alerts, we use some of them,
including the alert role, live regions and overlays, but all of them
have drawbacks.



On 3/29/21, Peter Weil < = EMAIL ADDRESS REMOVED = > wrote:
> Yes, the ARIA spec is quite clear about this. And while it does mention that
> nesting is permissible, examples are few and the implication (as I read it)
> is that these are probably limited to cases where there are multiple
> elements with such roles as application, document, and perhaps article(?). I
> think these kinds of cases are relatively rare, at least in my experience.
>
> As a developer. I work with all kinds of layout designs that do not take
> landmarks into account and unwittingly imply nested landmarks (that's
> another discussion), and it can be a challenge to adapt them to a
> landmarked-based structure. This is the main reason I asked my question.
>
> Regarding discoverability, I'd like to hear more about how or why content
> within, say, an aside, might be less discoverable if it were at the top
> level as opposed to be nested. In many cases, visual order or organization
> is flexible enough via CSS to achieve to decent balance between page
> structure and visual presentation. Regardless, if faced with a situation
> where visual design interfered with page structure (i.e., correct landmark
> usage), I might request more presentation flexibility for accessibility
> reasons.
>
> Peter
>
> --
> Peter Weil
> Web Developer
> University Marketing
> University of Wisconsin–Madison
>
>
>
> On 3/28/21, 9:21 PM, "WebAIM-Forum" < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>
> According to the specification, nesting a complementary landmark inside the
> main landmark is an ARIA violation because complementary landmarks should be
> top level landmarks (i.e. not contained within any other landmarks).
>
> https://www.w3.org/TR/wai-aria-1.1/#complementary
>
> https://www.w3.org/TR/wai-aria-practices/examples/landmarks/complementary.html
>
> Steve Green
> Managing Director
> Test Partners Ltd
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Birkir R. Gunnarsson
> Sent: 28 March 2021 16:14
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] The importance of landmarks to screen readers?
>
> I agree. I do not see how nesting a complementary landmark inside the main
> landmark is an ARIA violation.
>
> The argument goes that the complementary landmark contains content that is
> independent of the rest of the page. Therefore that content clearly doesn't
> belong in the main content of the page, which is the content unique to the
> page.
> It does make sense to a certain extent but it has to be balanced against
> context and discoverability.
> Say you have a hotel website that displays a widget with up-to-date weather
> information for the hotel location.
> I would put that in a complementary landmark (if I were to use any
> landmark).
> So from the nesting perspcetive that landmark shoud be put ouside the main
> landmark but if you put it above the main landmark it might not be easily
> dicoverable.
> If you put it below the main landmark (between main and footer) it probably
> would work but might not correspond to the visual order of the page.
> In a nice tropical setting you probably want to put the weather info in a
> prime location, adjacent to the reservation area.
> You'd want that info to be just as prominent to someone who doesn't see the
> page or someone uses an alternative content order.
> So if you can't ntest complementary inside main you have to choose between
> not using a landmark for this info or manipulating the content order to push
> it outside the main content, also making it less discoverable or relevant if
> you don't see the page.
> Ultimately, a landmark is supposed to aid accessibility. I think this rule
> actually can do the opposite, which either makes the complementary landmark
> not a good landmark or it needs to be revised.
> Cheers
> -B
>
> On 3/28/21, Bart Simons < = EMAIL ADDRESS REMOVED = > wrote:
>> Hello,
>>
>> For me there is no problem to nest landmarks. It is common to see a
>> <nav> inside the <header>. It could happen that a <nav> is part of the
>> <main>. E.g. a section with liks to related articles, pagination links ...
>>
>> <h1> outside of <main> is a failure for me, since <h1> is undoubtedly
>> part of the main content of a web page.
>>
>> An interesting debate is whether breadcrumbs should be part of <main>?
>>
>> Regards
>> Bart
>>
>> Op 25/03/2021 om 14:55 schreef Peter Weil:
>>> One thing I wonder about landmarks is nesting. It's not uncommon to
>>> see a <nav> element tucked inside <main>. Is this really a good idea?
>>> My impression is that landmarks ought to kept at the top level unless
>>> there is a compelling reason (which does not include css or layout
>>> constraints) to do so.
>>>
>>> It's also common is to see the heading (e.g., <h1>) for <main> to be
>>> located outside of <main>. How important is it to keep these together
>>> under the same landmark?
>>>
>>> --
>>> Peter Weil
>>> Web Developer
>>> University Marketing
>>> University of Wisconsin–Madison
>>>
>>>
>>> On 3/23/21, 3:08 PM, "WebAIM-Forum"
>>> < = EMAIL ADDRESS REMOVED = >
>>> wrote:
>>>
>>>
>>> Hello,
>>>
>>> My dev team and I are currently having a discussion about the
>>> importance of landmarks in websites. I was under the impression that
>>> the guidance of WCAG suggests that each webpage should have at least
>>> one or two landmarks per page, to help give screenreader users the
>>> ability to understand the overall layout of the page, for example
>>> that the page has at least the landmarks:
>>>
>>> - a header (for overall site info such as website name)
>>> - a nav (with links to different pages within the site or different
>>> sections of the page if it's a page with a lot of different content
>>> such as a long scroll type website)
>>> - a main for the content of the page
>>>
>>> We were working on a website that had a nav landmark that was by
>>> default hidden as a landmark when the page loaded (in NVDA it was not
>>> showing as anything under the Landmarks list in Elements List) and
>>> only became visible as a landmark once a hamburger menu was opened.
>>>
>>> I had flagged this as a WCAG failure, because the user has no way to
>>> know the nav landmark is there until they open the nav by hamburger
>>> button (and how can they open the nav when they don't know it's
>>> there? a sort of
>>> catch-22 situation) and I had assumed that screenreader users would
>>> want the nav landmark to be visible by default, either accessible by
>>> keyboard shortcut or by the Landmarks list.
>>>
>>> Have I given the nav landmark identity too much importance, that it
>>> must be identified by the screenreader officially as a nav landmark
>>> by default when the page loads? If the nav was clearly labelled for
>>> what it is (ie Main
>>> menu) and clear instructions are given for opening the menu by the
>>> hamburger icon, and otherwise is read out clearly by the screenreader
>>> and navigable by keyboard, would that be considered sufficient for
>>> passing the intent of WCAG's guidelines? Or do screen reader users
>>> first look at the list of page landmarks to help them move quickly
>>> between different parts of the page?
>>>
>>>
>>> *x*
>>> *Christine Hogenkamp (She, Her)*
>>> Front-end Developer
>>>
>>> CONTEXT CREATIVE
>>> 317 ADELAIDE ST. W., #500 | TORONTO, ON CANADA | M5V 1P9
>>> <https://maps.google.com/?q17+ADELAIDE+ST.+W.,+%23500%C2%A0+%7C%C2%
>>> A0+TORONTO,+ON+CANADA%C2%A0+%7C%C2%A0+M5V+1P9&entry=gmail&source=g>
>>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>
>>
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > http://webaim.org/discussion/archives
> > > > > > > > > >


--
Work hard. Have fun. Make history.

From: Don Mauck
Date: Mon, Mar 29 2021 8:31AM
Subject: Re: [External] :The importance of landmarks to screen readers?
← Previous message | Next message →

I've a question, I see headings used correctly yet the text that is important to read they put it in a Div. rather than using paragraph marking. Why do so many developers insist using Div.'s so much and ignore the use of paragraph markup.

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Birkir R. Gunnarsson
Sent: Monday, March 29, 2021 8:24 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [External] : Re: [WebAIM] The importance of landmarks to screen readers?

Peter

Many users, mysefl included, only review the header of a website once, then use the main content landmark, the h1 heading at the start of the main content (if site is well implemented) or use the skip link to jump straight to the main content of a page and explore from there.
If you place a complementary content prior to the main content, e.g.
an alert or special announcement, a user who does not see the page and uses a methodology that involves jumping to the main content, will not notice it.
If you, however, place this content right after the h1 heading inside the main content, users who use this methodology will spot it.
Since, in my line of business, we use complementary content primarily for special announcements or alerts (like closures or similar) we don't want users to miss them.
Yes, there are other ways to announce alerts, we use some of them, including the alert role, live regions and overlays, but all of them have drawbacks.



On 3/29/21, Peter Weil < = EMAIL ADDRESS REMOVED = > wrote:
> Yes, the ARIA spec is quite clear about this. And while it does
> mention that nesting is permissible, examples are few and the
> implication (as I read it) is that these are probably limited to cases
> where there are multiple elements with such roles as application,
> document, and perhaps article(?). I think these kinds of cases are relatively rare, at least in my experience.
>
> As a developer. I work with all kinds of layout designs that do not
> take landmarks into account and unwittingly imply nested landmarks
> (that's another discussion), and it can be a challenge to adapt them
> to a landmarked-based structure. This is the main reason I asked my question.
>
> Regarding discoverability, I'd like to hear more about how or why
> content within, say, an aside, might be less discoverable if it were
> at the top level as opposed to be nested. In many cases, visual order
> or organization is flexible enough via CSS to achieve to decent
> balance between page structure and visual presentation. Regardless, if
> faced with a situation where visual design interfered with page
> structure (i.e., correct landmark usage), I might request more
> presentation flexibility for accessibility reasons.
>
> Peter
>
> --
> Peter Weil
> Web Developer
> University Marketing
> University of Wisconsin–Madison
>
>
>
> On 3/28/21, 9:21 PM, "WebAIM-Forum"
> < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>
> According to the specification, nesting a complementary landmark
> inside the main landmark is an ARIA violation because complementary
> landmarks should be top level landmarks (i.e. not contained within any other landmarks).
>
> https://urldefense.com/v3/__https://www.w3.org/TR/wai-aria-1.1/*comple
> mentary__;Iw!!GqivPVa7Brio!JYHY3ryV578b8ErIiiqYi8UANfP4tEwcWLPpmXopR_s
> L3G_v6nuG_z0jliwv3ww$
>
> https://urldefense.com/v3/__https://www.w3.org/TR/wai-aria-practices/e
> xamples/landmarks/complementary.html__;!!GqivPVa7Brio!JYHY3ryV578b8ErI
> iiqYi8UANfP4tEwcWLPpmXopR_sL3G_v6nuG_z0jUDTIyAE$
>
> Steve Green
> Managing Director
> Test Partners Ltd
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Birkir R. Gunnarsson
> Sent: 28 March 2021 16:14
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] The importance of landmarks to screen readers?
>
> I agree. I do not see how nesting a complementary landmark inside the
> main landmark is an ARIA violation.
>
> The argument goes that the complementary landmark contains content
> that is independent of the rest of the page. Therefore that content
> clearly doesn't belong in the main content of the page, which is the
> content unique to the page.
> It does make sense to a certain extent but it has to be balanced
> against context and discoverability.
> Say you have a hotel website that displays a widget with up-to-date
> weather information for the hotel location.
> I would put that in a complementary landmark (if I were to use any
> landmark).
> So from the nesting perspcetive that landmark shoud be put ouside the
> main landmark but if you put it above the main landmark it might not
> be easily dicoverable.
> If you put it below the main landmark (between main and footer) it
> probably would work but might not correspond to the visual order of the page.
> In a nice tropical setting you probably want to put the weather info
> in a prime location, adjacent to the reservation area.
> You'd want that info to be just as prominent to someone who doesn't
> see the page or someone uses an alternative content order.
> So if you can't ntest complementary inside main you have to choose
> between not using a landmark for this info or manipulating the content
> order to push it outside the main content, also making it less
> discoverable or relevant if you don't see the page.
> Ultimately, a landmark is supposed to aid accessibility. I think this
> rule actually can do the opposite, which either makes the
> complementary landmark not a good landmark or it needs to be revised.
> Cheers
> -B
>
> On 3/28/21, Bart Simons < = EMAIL ADDRESS REMOVED = > wrote:
>> Hello,
>>
>> For me there is no problem to nest landmarks. It is common to see a
>> <nav> inside the <header>. It could happen that a <nav> is part of
>> the <main>. E.g. a section with liks to related articles, pagination links ...
>>
>> <h1> outside of <main> is a failure for me, since <h1> is undoubtedly
>> part of the main content of a web page.
>>
>> An interesting debate is whether breadcrumbs should be part of <main>?
>>
>> Regards
>> Bart
>>
>> Op 25/03/2021 om 14:55 schreef Peter Weil:
>>> One thing I wonder about landmarks is nesting. It's not uncommon to
>>> see a <nav> element tucked inside <main>. Is this really a good idea?
>>> My impression is that landmarks ought to kept at the top level
>>> unless there is a compelling reason (which does not include css or
>>> layout
>>> constraints) to do so.
>>>
>>> It's also common is to see the heading (e.g., <h1>) for <main> to be
>>> located outside of <main>. How important is it to keep these
>>> together under the same landmark?
>>>
>>> --
>>> Peter Weil
>>> Web Developer
>>> University Marketing
>>> University of Wisconsin–Madison
>>>
>>>
>>> On 3/23/21, 3:08 PM, "WebAIM-Forum"
>>> < = EMAIL ADDRESS REMOVED = >
>>> wrote:
>>>
>>>
>>> Hello,
>>>
>>> My dev team and I are currently having a discussion about the
>>> importance of landmarks in websites. I was under the impression that
>>> the guidance of WCAG suggests that each webpage should have at least
>>> one or two landmarks per page, to help give screenreader users the
>>> ability to understand the overall layout of the page, for example
>>> that the page has at least the landmarks:
>>>
>>> - a header (for overall site info such as website name)
>>> - a nav (with links to different pages within the site or different
>>> sections of the page if it's a page with a lot of different content
>>> such as a long scroll type website)
>>> - a main for the content of the page
>>>
>>> We were working on a website that had a nav landmark that was by
>>> default hidden as a landmark when the page loaded (in NVDA it was
>>> not showing as anything under the Landmarks list in Elements List)
>>> and only became visible as a landmark once a hamburger menu was opened.
>>>
>>> I had flagged this as a WCAG failure, because the user has no way to
>>> know the nav landmark is there until they open the nav by hamburger
>>> button (and how can they open the nav when they don't know it's
>>> there? a sort of
>>> catch-22 situation) and I had assumed that screenreader users would
>>> want the nav landmark to be visible by default, either accessible by
>>> keyboard shortcut or by the Landmarks list.
>>>
>>> Have I given the nav landmark identity too much importance, that it
>>> must be identified by the screenreader officially as a nav landmark
>>> by default when the page loads? If the nav was clearly labelled for
>>> what it is (ie Main
>>> menu) and clear instructions are given for opening the menu by the
>>> hamburger icon, and otherwise is read out clearly by the
>>> screenreader and navigable by keyboard, would that be considered
>>> sufficient for passing the intent of WCAG's guidelines? Or do screen
>>> reader users first look at the list of page landmarks to help them
>>> move quickly between different parts of the page?
>>>
>>>
>>> *x*
>>> *Christine Hogenkamp (She, Her)*
>>> Front-end Developer
>>>
>>> CONTEXT CREATIVE
>>> 317 ADELAIDE ST. W., #500 | TORONTO, ON CANADA | M5V 1P9
>>> <https://urldefense.com/v3/__https://maps.google.com/?q17*ADELAIDE
>>> *ST.*W.,**A23500**C7C*C2*__;KysrKyXCoCslJSU!!GqivPVa7Brio!JYHY3ryV57
>>> 8b8ErIiiqYi8UANfP4tEwcWLPpmXopR_sL3G_v6nuG_z0jT47f4Aw$
>>> A0+TORONTO,+ON+CANADA%C2%A0+%7C%C2%A0+M5V+1P9&entry=gmail&source=g>
>>> >>> >>> https://urldefense.com/v3/__http://list.webaim.org/__;!!GqivPVa7Brio
>>> !JYHY3ryV578b8ErIiiqYi8UANfP4tEwcWLPpmXopR_sL3G_v6nuG_z0jOioJefw$
>>> List archives at
>>> https://urldefense.com/v3/__http://webaim.org/discussion/archives__;
>>> !!GqivPVa7Brio!JYHY3ryV578b8ErIiiqYi8UANfP4tEwcWLPpmXopR_sL3G_v6nuG_
>>> z0jeRHFHrk$ >>> >>> >>> https://urldefense.com/v3/__http://list.webaim.org/__;!!GqivPVa7Brio
>>> !JYHY3ryV578b8ErIiiqYi8UANfP4tEwcWLPpmXopR_sL3G_v6nuG_z0jOioJefw$
>>> List archives at
>>> https://urldefense.com/v3/__http://webaim.org/discussion/archives__;
>>> !!GqivPVa7Brio!JYHY3ryV578b8ErIiiqYi8UANfP4tEwcWLPpmXopR_sL3G_v6nuG_
>>> z0jeRHFHrk$ >>
>>
>> >> >> https://urldefense.com/v3/__http://list.webaim.org/__;!!GqivPVa7Brio!
>> JYHY3ryV578b8ErIiiqYi8UANfP4tEwcWLPpmXopR_sL3G_v6nuG_z0jOioJefw$
>> List archives at
>> https://urldefense.com/v3/__http://webaim.org/discussion/archives__;!
>> !GqivPVa7Brio!JYHY3ryV578b8ErIiiqYi8UANfP4tEwcWLPpmXopR_sL3G_v6nuG_z0
>> jeRHFHrk$ >>
>
>
> --
> Work hard. Have fun. Make history.
> > > https://urldefense.com/v3/__http://list.webaim.org/__;!!GqivPVa7Brio!J
> YHY3ryV578b8ErIiiqYi8UANfP4tEwcWLPpmXopR_sL3G_v6nuG_z0jOioJefw$ List
> archives at
> https://urldefense.com/v3/__http://webaim.org/discussion/archives__;!!
> GqivPVa7Brio!JYHY3ryV578b8ErIiiqYi8UANfP4tEwcWLPpmXopR_sL3G_v6nuG_z0je
> RHFHrk$ > > > https://urldefense.com/v3/__http://list.webaim.org/__;!!GqivPVa7Brio!J
> YHY3ryV578b8ErIiiqYi8UANfP4tEwcWLPpmXopR_sL3G_v6nuG_z0jOioJefw$
> List archives at
> https://urldefense.com/v3/__http://webaim.org/discussion/archives__;!!
> GqivPVa7Brio!JYHY3ryV578b8ErIiiqYi8UANfP4tEwcWLPpmXopR_sL3G_v6nuG_z0je
> RHFHrk$ > > > https://urldefense.com/v3/__http://list.webaim.org/__;!!GqivPVa7Brio!J
> YHY3ryV578b8ErIiiqYi8UANfP4tEwcWLPpmXopR_sL3G_v6nuG_z0jOioJefw$
> List archives at
> https://urldefense.com/v3/__http://webaim.org/discussion/archives__;!!
> GqivPVa7Brio!JYHY3ryV578b8ErIiiqYi8UANfP4tEwcWLPpmXopR_sL3G_v6nuG_z0je
> RHFHrk$ >


--
Work hard. Have fun. Make history.

From: Peter Weil
Date: Mon, Mar 29 2021 9:16AM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

Gunnar,

Thanks for that explanation.

It sounds as though there might be a disconnect between a) the ARIA spec; b) how some/many users navigate sites in practice; and c) skip link implementations that skip not only navigation links, but complementary content as well.

Perhaps the latter could be mitigated by a skip link implementation that includes the complementary content as an option. A & b pose a real difficulty for developers who want or must follow the ARIA spec, but may risk failing to communicate with users who navigate sites in ways that the spec does not account for or possibly undermines (for lack of a better term).



On 3/29/21, 9:24 AM, "WebAIM-Forum" < = EMAIL ADDRESS REMOVED = > wrote:


Peter

Many users, mysefl included, only review the header of a website once,
then use the main content landmark, the h1 heading at the start of the
main content (if site is well implemented) or use the skip link to
jump straight to the main content of a page and explore from there.
If you place a complementary content prior to the main content, e.g.
an alert or special announcement, a user who does not see the page and
uses a methodology that involves jumping to the main content, will not
notice it.
If you, however, place this content right after the h1 heading inside
the main content, users who use this methodology will spot it.
Since, in my line of business, we use complementary content primarily
for special announcements or alerts (like closures or similar) we
don't want users to miss them.
Yes, there are other ways to announce alerts, we use some of them,
including the alert role, live regions and overlays, but all of them
have drawbacks.



On 3/29/21, Peter Weil < = EMAIL ADDRESS REMOVED = > wrote:
> Yes, the ARIA spec is quite clear about this. And while it does mention that
> nesting is permissible, examples are few and the implication (as I read it)
> is that these are probably limited to cases where there are multiple
> elements with such roles as application, document, and perhaps article(?). I
> think these kinds of cases are relatively rare, at least in my experience.
>
> As a developer. I work with all kinds of layout designs that do not take
> landmarks into account and unwittingly imply nested landmarks (that's
> another discussion), and it can be a challenge to adapt them to a
> landmarked-based structure. This is the main reason I asked my question.
>
> Regarding discoverability, I'd like to hear more about how or why content
> within, say, an aside, might be less discoverable if it were at the top
> level as opposed to be nested. In many cases, visual order or organization
> is flexible enough via CSS to achieve to decent balance between page
> structure and visual presentation. Regardless, if faced with a situation
> where visual design interfered with page structure (i.e., correct landmark
> usage), I might request more presentation flexibility for accessibility
> reasons.
>
> Peter
>
> --
> Peter Weil
> Web Developer
> University Marketing
> University of Wisconsin–Madison
>
>
>
> On 3/28/21, 9:21 PM, "WebAIM-Forum" < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>
> According to the specification, nesting a complementary landmark inside the
> main landmark is an ARIA violation because complementary landmarks should be
> top level landmarks (i.e. not contained within any other landmarks).
>
> https://www.w3.org/TR/wai-aria-1.1/#complementary
>
> https://www.w3.org/TR/wai-aria-practices/examples/landmarks/complementary.html
>
> Steve Green
> Managing Director
> Test Partners Ltd
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Birkir R. Gunnarsson
> Sent: 28 March 2021 16:14
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] The importance of landmarks to screen readers?
>
> I agree. I do not see how nesting a complementary landmark inside the main
> landmark is an ARIA violation.
>
> The argument goes that the complementary landmark contains content that is
> independent of the rest of the page. Therefore that content clearly doesn't
> belong in the main content of the page, which is the content unique to the
> page.
> It does make sense to a certain extent but it has to be balanced against
> context and discoverability.
> Say you have a hotel website that displays a widget with up-to-date weather
> information for the hotel location.
> I would put that in a complementary landmark (if I were to use any
> landmark).
> So from the nesting perspcetive that landmark shoud be put ouside the main
> landmark but if you put it above the main landmark it might not be easily
> dicoverable.
> If you put it below the main landmark (between main and footer) it probably
> would work but might not correspond to the visual order of the page.
> In a nice tropical setting you probably want to put the weather info in a
> prime location, adjacent to the reservation area.
> You'd want that info to be just as prominent to someone who doesn't see the
> page or someone uses an alternative content order.
> So if you can't ntest complementary inside main you have to choose between
> not using a landmark for this info or manipulating the content order to push
> it outside the main content, also making it less discoverable or relevant if
> you don't see the page.
> Ultimately, a landmark is supposed to aid accessibility. I think this rule
> actually can do the opposite, which either makes the complementary landmark
> not a good landmark or it needs to be revised.
> Cheers
> -B
>
> On 3/28/21, Bart Simons < = EMAIL ADDRESS REMOVED = > wrote:
>> Hello,
>>
>> For me there is no problem to nest landmarks. It is common to see a
>> <nav> inside the <header>. It could happen that a <nav> is part of the
>> <main>. E.g. a section with liks to related articles, pagination links ...
>>
>> <h1> outside of <main> is a failure for me, since <h1> is undoubtedly
>> part of the main content of a web page.
>>
>> An interesting debate is whether breadcrumbs should be part of <main>?
>>
>> Regards
>> Bart
>>
>> Op 25/03/2021 om 14:55 schreef Peter Weil:
>>> One thing I wonder about landmarks is nesting. It's not uncommon to
>>> see a <nav> element tucked inside <main>. Is this really a good idea?
>>> My impression is that landmarks ought to kept at the top level unless
>>> there is a compelling reason (which does not include css or layout
>>> constraints) to do so.
>>>
>>> It's also common is to see the heading (e.g., <h1>) for <main> to be
>>> located outside of <main>. How important is it to keep these together
>>> under the same landmark?
>>>
>>> --
>>> Peter Weil
>>> Web Developer
>>> University Marketing
>>> University of Wisconsin–Madison
>>>
>>>
>>> On 3/23/21, 3:08 PM, "WebAIM-Forum"
>>> < = EMAIL ADDRESS REMOVED = >
>>> wrote:
>>>
>>>
>>> Hello,
>>>
>>> My dev team and I are currently having a discussion about the
>>> importance of landmarks in websites. I was under the impression that
>>> the guidance of WCAG suggests that each webpage should have at least
>>> one or two landmarks per page, to help give screenreader users the
>>> ability to understand the overall layout of the page, for example
>>> that the page has at least the landmarks:
>>>
>>> - a header (for overall site info such as website name)
>>> - a nav (with links to different pages within the site or different
>>> sections of the page if it's a page with a lot of different content
>>> such as a long scroll type website)
>>> - a main for the content of the page
>>>
>>> We were working on a website that had a nav landmark that was by
>>> default hidden as a landmark when the page loaded (in NVDA it was not
>>> showing as anything under the Landmarks list in Elements List) and
>>> only became visible as a landmark once a hamburger menu was opened.
>>>
>>> I had flagged this as a WCAG failure, because the user has no way to
>>> know the nav landmark is there until they open the nav by hamburger
>>> button (and how can they open the nav when they don't know it's
>>> there? a sort of
>>> catch-22 situation) and I had assumed that screenreader users would
>>> want the nav landmark to be visible by default, either accessible by
>>> keyboard shortcut or by the Landmarks list.
>>>
>>> Have I given the nav landmark identity too much importance, that it
>>> must be identified by the screenreader officially as a nav landmark
>>> by default when the page loads? If the nav was clearly labelled for
>>> what it is (ie Main
>>> menu) and clear instructions are given for opening the menu by the
>>> hamburger icon, and otherwise is read out clearly by the screenreader
>>> and navigable by keyboard, would that be considered sufficient for
>>> passing the intent of WCAG's guidelines? Or do screen reader users
>>> first look at the list of page landmarks to help them move quickly
>>> between different parts of the page?
>>>
>>>
>>> *x*
>>> *Christine Hogenkamp (She, Her)*
>>> Front-end Developer
>>>
>>> CONTEXT CREATIVE
>>> 317 ADELAIDE ST. W., #500 | TORONTO, ON CANADA | M5V 1P9
>>> <https://maps.google.com/?q17+ADELAIDE+ST.+W.,+%23500%C2%A0+%7C%C2%
>>> A0+TORONTO,+ON+CANADA%C2%A0+%7C%C2%A0+M5V+1P9&entry=gmail&source=g>
>>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>
>>
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > http://webaim.org/discussion/archives
> > > > > > > > > >


--
Work hard. Have fun. Make history.

From: glen walker
Date: Mon, Mar 29 2021 9:51AM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

I tried to avoid this because I'm kind of nit-picking things a bit but be
careful when you state something violates the spec.

The spec for the complementary landmark says "A supporting section of the
document, designed to be complementary to the main content at a similar
level in the DOM hierarchy, but remains meaningful when separated from the
main content." There's nothing in the wording that requires the developer
to do anything in particular. It hints at putting a complementary landmark
at the same level of the DOM as the main landmark but is certainly not
required, so *not* doing that is not a violation of anything.

If the spec requires a developer to do something, it will say "Authors
MUST...".
If the spec strongly encourages but not necessarily requires a developer to
do something, it will say "Authors SHOULD..."
In the case of complementary, it doesn't say either.

WCAG tells you how to find the definitions of MUST and SHOULD at
https://www.w3.org/TR/WCAG21/#interpreting-normative-requirements
If you follow the footnotes, it'll eventually take you to
https://tools.ietf.org/html/rfc2119 where you'll see MUST means required
and SHOULD means recommended (or strongly encouraged).

Notice in the complementary spec that it says "User agents SHOULD treat
elements with the role of complementary as navigational landmarks."
That means browsers (user agents) are strongly encouraged to surface the
complementary role as a landmark, but there might be cases where it's not.

Take a look at the region role, https://www.w3.org/TR/wai-aria/#region.
Most of you probably know that a region landmark will be ignored by most
screen readers if the region doesn't have an accessible name. Did you know
that providing an accessible name is required? It's a MUST. "Authors MUST
give each element with role region a brief label that describes the purpose
of the content in the region." So if your region doesn't have an
accessible name, you are violating the spec. There are several SHOULDs for
region roles too.

Glen

From: Steve Green
Date: Mon, Mar 29 2021 10:19AM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

The specification also states "The complementary role indicates that contained content is relevant to the main content." That only makes sense if the complementary landmark is outside the main content.

Steve


-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen walker
Sent: 29 March 2021 16:52
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] The importance of landmarks to screen readers?

I tried to avoid this because I'm kind of nit-picking things a bit but be careful when you state something violates the spec.

The spec for the complementary landmark says "A supporting section of the document, designed to be complementary to the main content at a similar level in the DOM hierarchy, but remains meaningful when separated from the main content." There's nothing in the wording that requires the developer to do anything in particular. It hints at putting a complementary landmark at the same level of the DOM as the main landmark but is certainly not required, so *not* doing that is not a violation of anything.

If the spec requires a developer to do something, it will say "Authors MUST...".
If the spec strongly encourages but not necessarily requires a developer to do something, it will say "Authors SHOULD..."
In the case of complementary, it doesn't say either.

WCAG tells you how to find the definitions of MUST and SHOULD at https://www.w3.org/TR/WCAG21/#interpreting-normative-requirements
If you follow the footnotes, it'll eventually take you to
https://tools.ietf.org/html/rfc2119 where you'll see MUST means required and SHOULD means recommended (or strongly encouraged).

Notice in the complementary spec that it says "User agents SHOULD treat elements with the role of complementary as navigational landmarks."
That means browsers (user agents) are strongly encouraged to surface the complementary role as a landmark, but there might be cases where it's not.

Take a look at the region role, https://www.w3.org/TR/wai-aria/#region.
Most of you probably know that a region landmark will be ignored by most screen readers if the region doesn't have an accessible name. Did you know that providing an accessible name is required? It's a MUST. "Authors MUST give each element with role region a brief label that describes the purpose of the content in the region." So if your region doesn't have an accessible name, you are violating the spec. There are several SHOULDs for region roles too.

Glen

From: jds.listserv@gmail.com
Date: Mon, Mar 29 2021 12:23PM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

Personally, I feel that landmarks are useful in supplementing information about where/what you are dealing with from a user perspective. E.g. this is complementary to the content

I haven't found landmarks very practical as a faster way to navigate content compared to headings (or other methods) or as fast. With the exception of the "main" area of content. Likely that's why screen reader users tend to not bother with them.


-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Peter Weil
Sent: March 29, 2021 11:17 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] The importance of landmarks to screen readers?

Gunnar,

Thanks for that explanation.

It sounds as though there might be a disconnect between a) the ARIA spec; b) how some/many users navigate sites in practice; and c) skip link implementations that skip not only navigation links, but complementary content as well.

Perhaps the latter could be mitigated by a skip link implementation that includes the complementary content as an option. A & b pose a real difficulty for developers who want or must follow the ARIA spec, but may risk failing to communicate with users who navigate sites in ways that the spec does not account for or possibly undermines (for lack of a better term).



On 3/29/21, 9:24 AM, "WebAIM-Forum" < = EMAIL ADDRESS REMOVED = > wrote:


Peter

Many users, mysefl included, only review the header of a website once, then use the main content landmark, the h1 heading at the start of the main content (if site is well implemented) or use the skip link to jump straight to the main content of a page and explore from there.
If you place a complementary content prior to the main content, e.g.
an alert or special announcement, a user who does not see the page and uses a methodology that involves jumping to the main content, will not notice it.
If you, however, place this content right after the h1 heading inside the main content, users who use this methodology will spot it.
Since, in my line of business, we use complementary content primarily for special announcements or alerts (like closures or similar) we don't want users to miss them.
Yes, there are other ways to announce alerts, we use some of them, including the alert role, live regions and overlays, but all of them have drawbacks.



On 3/29/21, Peter Weil < = EMAIL ADDRESS REMOVED = > wrote:
> Yes, the ARIA spec is quite clear about this. And while it does
> mention that nesting is permissible, examples are few and the
> implication (as I read it) is that these are probably limited to cases
> where there are multiple elements with such roles as application,
> document, and perhaps article(?). I think these kinds of cases are relatively rare, at least in my experience.
>
> As a developer. I work with all kinds of layout designs that do not
> take landmarks into account and unwittingly imply nested landmarks
> (that's another discussion), and it can be a challenge to adapt them
> to a landmarked-based structure. This is the main reason I asked my question.
>
> Regarding discoverability, I'd like to hear more about how or why
> content within, say, an aside, might be less discoverable if it were
> at the top level as opposed to be nested. In many cases, visual order
> or organization is flexible enough via CSS to achieve to decent
> balance between page structure and visual presentation. Regardless, if
> faced with a situation where visual design interfered with page
> structure (i.e., correct landmark usage), I might request more
> presentation flexibility for accessibility reasons.
>
> Peter
>
> --
> Peter Weil
> Web Developer
> University Marketing
> University of Wisconsin–Madison
>
>
>
> On 3/28/21, 9:21 PM, "WebAIM-Forum"
> < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>
> According to the specification, nesting a complementary landmark
> inside the main landmark is an ARIA violation because complementary
> landmarks should be top level landmarks (i.e. not contained within any other landmarks).
>
> https://www.w3.org/TR/wai-aria-1.1/#complementary
>
> https://www.w3.org/TR/wai-aria-practices/examples/landmarks/complement
> ary.html
>
> Steve Green
> Managing Director
> Test Partners Ltd
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Birkir R. Gunnarsson
> Sent: 28 March 2021 16:14
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] The importance of landmarks to screen readers?
>
> I agree. I do not see how nesting a complementary landmark inside the
> main landmark is an ARIA violation.
>
> The argument goes that the complementary landmark contains content
> that is independent of the rest of the page. Therefore that content
> clearly doesn't belong in the main content of the page, which is the
> content unique to the page.
> It does make sense to a certain extent but it has to be balanced
> against context and discoverability.
> Say you have a hotel website that displays a widget with up-to-date
> weather information for the hotel location.
> I would put that in a complementary landmark (if I were to use any
> landmark).
> So from the nesting perspcetive that landmark shoud be put ouside the
> main landmark but if you put it above the main landmark it might not
> be easily dicoverable.
> If you put it below the main landmark (between main and footer) it
> probably would work but might not correspond to the visual order of the page.
> In a nice tropical setting you probably want to put the weather info
> in a prime location, adjacent to the reservation area.
> You'd want that info to be just as prominent to someone who doesn't
> see the page or someone uses an alternative content order.
> So if you can't ntest complementary inside main you have to choose
> between not using a landmark for this info or manipulating the content
> order to push it outside the main content, also making it less
> discoverable or relevant if you don't see the page.
> Ultimately, a landmark is supposed to aid accessibility. I think this
> rule actually can do the opposite, which either makes the
> complementary landmark not a good landmark or it needs to be revised.
> Cheers
> -B
>
> On 3/28/21, Bart Simons < = EMAIL ADDRESS REMOVED = > wrote:
>> Hello,
>>
>> For me there is no problem to nest landmarks. It is common to see a
>> <nav> inside the <header>. It could happen that a <nav> is part of
>> the <main>. E.g. a section with liks to related articles, pagination links ...
>>
>> <h1> outside of <main> is a failure for me, since <h1> is undoubtedly
>> part of the main content of a web page.
>>
>> An interesting debate is whether breadcrumbs should be part of <main>?
>>
>> Regards
>> Bart
>>
>> Op 25/03/2021 om 14:55 schreef Peter Weil:
>>> One thing I wonder about landmarks is nesting. It's not uncommon to
>>> see a <nav> element tucked inside <main>. Is this really a good idea?
>>> My impression is that landmarks ought to kept at the top level
>>> unless there is a compelling reason (which does not include css or
>>> layout
>>> constraints) to do so.
>>>
>>> It's also common is to see the heading (e.g., <h1>) for <main> to be
>>> located outside of <main>. How important is it to keep these
>>> together under the same landmark?
>>>
>>> --
>>> Peter Weil
>>> Web Developer
>>> University Marketing
>>> University of Wisconsin–Madison
>>>
>>>
>>> On 3/23/21, 3:08 PM, "WebAIM-Forum"
>>> < = EMAIL ADDRESS REMOVED = >
>>> wrote:
>>>
>>>
>>> Hello,
>>>
>>> My dev team and I are currently having a discussion about the
>>> importance of landmarks in websites. I was under the impression that
>>> the guidance of WCAG suggests that each webpage should have at least
>>> one or two landmarks per page, to help give screenreader users the
>>> ability to understand the overall layout of the page, for example
>>> that the page has at least the landmarks:
>>>
>>> - a header (for overall site info such as website name)
>>> - a nav (with links to different pages within the site or different
>>> sections of the page if it's a page with a lot of different content
>>> such as a long scroll type website)
>>> - a main for the content of the page
>>>
>>> We were working on a website that had a nav landmark that was by
>>> default hidden as a landmark when the page loaded (in NVDA it was
>>> not showing as anything under the Landmarks list in Elements List)
>>> and only became visible as a landmark once a hamburger menu was opened.
>>>
>>> I had flagged this as a WCAG failure, because the user has no way to
>>> know the nav landmark is there until they open the nav by hamburger
>>> button (and how can they open the nav when they don't know it's
>>> there? a sort of
>>> catch-22 situation) and I had assumed that screenreader users would
>>> want the nav landmark to be visible by default, either accessible by
>>> keyboard shortcut or by the Landmarks list.
>>>
>>> Have I given the nav landmark identity too much importance, that it
>>> must be identified by the screenreader officially as a nav landmark
>>> by default when the page loads? If the nav was clearly labelled for
>>> what it is (ie Main
>>> menu) and clear instructions are given for opening the menu by the
>>> hamburger icon, and otherwise is read out clearly by the
>>> screenreader and navigable by keyboard, would that be considered
>>> sufficient for passing the intent of WCAG's guidelines? Or do screen
>>> reader users first look at the list of page landmarks to help them
>>> move quickly between different parts of the page?
>>>
>>>
>>> *x*
>>> *Christine Hogenkamp (She, Her)*
>>> Front-end Developer
>>>
>>> CONTEXT CREATIVE
>>> 317 ADELAIDE ST. W., #500 | TORONTO, ON CANADA | M5V 1P9
>>> <https://maps.google.com/?q17+ADELAIDE+ST.+W.,+%23500%C2%A0+%7C%C2
>>> %
>>> A0+TORONTO,+ON+CANADA%C2%A0+%7C%C2%A0+M5V+1P9&entry=gmail&source=g>
>>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>
>>
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >


--
Work hard. Have fun. Make history.

From: glen walker
Date: Mon, Mar 29 2021 1:09PM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

Agreed, but it's not a violation if that is not followed. If the spec said
"Authors MUST (or SHOULD) specify a complementary landmark outside the main
content...", then *that* would be a violation if not followed.

Like I said, I know my point was nit-picky, but I tend to be pretty literal
about "violations" of spec only if they go against MUST/SHOULD sections.

On Mon, Mar 29, 2021 at 10:19 AM Steve Green < = EMAIL ADDRESS REMOVED = >
wrote:

> The specification also states "The complementary role indicates that
> contained content is relevant to the main content." That only makes sense
> if the complementary landmark is outside the main content.
>
> Steve
>
>
>

From: Peter Weil
Date: Mon, Mar 29 2021 7:04PM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

The ARIA Landmark Examples pages do use the word "should". These read like a normative document, but they're technically not part of the specification (are they?).

" banner, main, complementary and contentinfo landmarks should be top level landmarks.
"complementary landmarks should be top level landmarks (e.g. not contained within any other landmarks)."

https://www.w3.org/TR/wai-aria-practices/examples/landmarks/index.html
https://www.w3.org/TR/wai-aria-practices/examples/landmarks/complementary.html

I don't know what these example pages' exact technical or normative status is, but if they incorrectly reflect the spec, that seems like a problem. If they do, then the proper usage of complementary landmarks seems pretty clear. I wonder whether there is anyone who can tell us which of these is true.
-Peter


On 3/29/21, 2:09 PM, "WebAIM-Forum" < = EMAIL ADDRESS REMOVED = > wrote:


Agreed, but it's not a violation if that is not followed. If the spec said
"Authors MUST (or SHOULD) specify a complementary landmark outside the main
content...", then *that* would be a violation if not followed.

Like I said, I know my point was nit-picky, but I tend to be pretty literal
about "violations" of spec only if they go against MUST/SHOULD sections.

On Mon, Mar 29, 2021 at 10:19 AM Steve Green < = EMAIL ADDRESS REMOVED = >
wrote:

> The specification also states "The complementary role indicates that
> contained content is relevant to the main content." That only makes sense
> if the complementary landmark is outside the main content.
>
> Steve
>
>
>

From: Birkir R. Gunnarsson
Date: Mon, Mar 29 2021 7:25PM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

I recommend landmark priarmily when users need to know the beginning
and end of the content. Headings onlhy mark the beginning. For users
to know where a section labeled by a heading ends, there must be a
heading, at the same level or lower, that marks the start of the next
independent section of content. This is not always the case, and then
you have to either put in a screen reader only heading or use the most
appropriate landmark.
And, well spotted Glen, this is why I disagree with the fact that
nesting a complementary landmark inside a main landmark is an outright
ARIA violation.
I see where they are coming from but I also think there´s a
fundamental disconnect between the spec and what works best for users.
If there is, I err on the side of the usability.


On 3/29/21, Peter Weil < = EMAIL ADDRESS REMOVED = > wrote:
> The ARIA Landmark Examples pages do use the word "should". These read like a
> normative document, but they're technically not part of the specification
> (are they?).
>
> " banner, main, complementary and contentinfo landmarks should be top level
> landmarks.
> "complementary landmarks should be top level landmarks (e.g. not contained
> within any other landmarks)."
>
> https://www.w3.org/TR/wai-aria-practices/examples/landmarks/index.html
> https://www.w3.org/TR/wai-aria-practices/examples/landmarks/complementary.html
>
> I don't know what these example pages' exact technical or normative status
> is, but if they incorrectly reflect the spec, that seems like a problem. If
> they do, then the proper usage of complementary landmarks seems pretty
> clear. I wonder whether there is anyone who can tell us which of these is
> true.
> -Peter
>
>
> On 3/29/21, 2:09 PM, "WebAIM-Forum" < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>
> Agreed, but it's not a violation if that is not followed. If the spec said
> "Authors MUST (or SHOULD) specify a complementary landmark outside the main
> content...", then *that* would be a violation if not followed.
>
> Like I said, I know my point was nit-picky, but I tend to be pretty literal
> about "violations" of spec only if they go against MUST/SHOULD sections.
>
> On Mon, Mar 29, 2021 at 10:19 AM Steve Green
> < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> The specification also states "The complementary role indicates that
>> contained content is relevant to the main content." That only makes sense
>> if the complementary landmark is outside the main content.
>>
>> Steve
>>
>>
>>
> > > > > > > > >


--
Work hard. Have fun. Make history.

From: Steve Green
Date: Tue, Mar 30 2021 2:41AM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

Birkir, everything in the specification contradicts your viewpoint. There are statements that the complementary landmark should be at the top level and there are statements that it is at the same level as the main landmark. There is also a statement that it is related to the main landmark, which only makes sense if it is not inside it. There is not a single aspect of the specification or the examples that supports your view that the complementary landmark can be inside the main landmark. You are relying entirely on the bad drafting of the specification, which omits the word MUST where it is clearly the author's intention.

I profoundly hope that the W3C engage professional standards authors for WCAG 3.0 to avoid this sort of nonsense. It's too important to leave to enthusiastic amateurs. The countless discussions we have had in this forum show that there is a massive problem with ambiguity, errors, omissions and contradictions. I think it's amazing that people have given up so much of their time, presumably unpaid, to write the specifications and examples we have had to date, but it's time to improve the quality.

Steve


-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Birkir R. Gunnarsson
Sent: 30 March 2021 02:25
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] The importance of landmarks to screen readers?

I recommend landmark priarmily when users need to know the beginning and end of the content. Headings onlhy mark the beginning. For users to know where a section labeled by a heading ends, there must be a heading, at the same level or lower, that marks the start of the next independent section of content. This is not always the case, and then you have to either put in a screen reader only heading or use the most appropriate landmark.
And, well spotted Glen, this is why I disagree with the fact that nesting a complementary landmark inside a main landmark is an outright ARIA violation.
I see where they are coming from but I also think there´s a fundamental disconnect between the spec and what works best for users.
If there is, I err on the side of the usability.


On 3/29/21, Peter Weil < = EMAIL ADDRESS REMOVED = > wrote:
> The ARIA Landmark Examples pages do use the word "should". These read
> like a normative document, but they're technically not part of the
> specification (are they?).
>
> " banner, main, complementary and contentinfo landmarks should be top
> level landmarks.
> "complementary landmarks should be top level landmarks (e.g. not
> contained within any other landmarks)."
>
> https://www.w3.org/TR/wai-aria-practices/examples/landmarks/index.html
> https://www.w3.org/TR/wai-aria-practices/examples/landmarks/complement
> ary.html
>
> I don't know what these example pages' exact technical or normative
> status is, but if they incorrectly reflect the spec, that seems like a
> problem. If they do, then the proper usage of complementary landmarks
> seems pretty clear. I wonder whether there is anyone who can tell us
> which of these is true.
> -Peter
>
>
> On 3/29/21, 2:09 PM, "WebAIM-Forum"
> < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>
> Agreed, but it's not a violation if that is not followed. If the spec
> said "Authors MUST (or SHOULD) specify a complementary landmark
> outside the main content...", then *that* would be a violation if not followed.
>
> Like I said, I know my point was nit-picky, but I tend to be pretty
> literal about "violations" of spec only if they go against MUST/SHOULD sections.
>
> On Mon, Mar 29, 2021 at 10:19 AM Steve Green
> < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> The specification also states "The complementary role indicates that
>> contained content is relevant to the main content." That only makes
>> sense if the complementary landmark is outside the main content.
>>
>> Steve
>>
>>
>>
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >


--
Work hard. Have fun. Make history.

From: Mallory
Date: Tue, Mar 30 2021 2:53AM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

Steve said:
> The countless discussions we have had in this forum show that there is a massive problem with ambiguity, errors, omissions and contradictions.

3.0, from the bits I've seen, does not seem to help with this. With things like "passes alt text at x%" it feels even fuzzier, if that's possible.

I still think, since WCAG is being used as the basis for laws in more and more places (yet is not a judicial document) that maybe the a11y world needs its own "judicial system".

That is, specific instances of something are brought as a "case" to a "judge" and things like rulings can be made on things like "what does the text literally say" or "what is the spirit of this SC" etc. Later cases can refer to earlier cases and they can all be stored in one place where anyone can search to look things up; it would be as flexible as law interpretation (laws interpreted one way may a decade later be interpreted differently due to how stuff changes), and dates would be clear so people can see if they find a page stating x that it's immediately clear whether something more recent (y) has superceded it (just recently found a dev relying on information from 2013 about the vapourware known as the HTML5 Outline).

I'm an auditor for my work and have been doing accessicrap since ~2006 or so but I'm always going to be an "enthusiastic amateur". There are very, very few people I would use the term "expert" for and most of them have been spec editors... and as a spec editor I still would not necessarily consider them "experts" on the practical side (what are real authors and real users doing? What is more AT and similar software doing?).

Without something like the judicial-system setup, some decent majority of things like audits are going to be based on opinions without the backup of something like agreed-upon precedence or the arguments (as in a judge's final argument explaining why they ruled the way they did) as a reference beyond "well but we're all pretty sure the spec author *meant* this thing they didn't explicitly say" and other fluffy stuff.

cheers,
_mallory

From: Barry
Date: Tue, Mar 30 2021 3:09AM
Subject: Re: Judicial system, was The importance of landmarks to screen readers?
← Previous message | Next message →

What an incredibly useful system that would be. I think the problem we currently have is that all cases seem to be settled out of court. I'm not sure, but does that then mean that there would be no case law?

Cheers

Barry


-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Mallory
Sent: 30 March 2021 9:54 AM
To: Steve Green < = EMAIL ADDRESS REMOVED = >; WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] The importance of landmarks to screen readers?

Steve said:
> The countless discussions we have had in this forum show that there is a massive problem with ambiguity, errors, omissions and contradictions.

3.0, from the bits I've seen, does not seem to help with this. With things like "passes alt text at x%" it feels even fuzzier, if that's possible.

I still think, since WCAG is being used as the basis for laws in more and more places (yet is not a judicial document) that maybe the a11y world needs its own "judicial system".

That is, specific instances of something are brought as a "case" to a "judge" and things like rulings can be made on things like "what does the text literally say" or "what is the spirit of this SC" etc. Later cases can refer to earlier cases and they can all be stored in one place where anyone can search to look things up; it would be as flexible as law interpretation (laws interpreted one way may a decade later be interpreted differently due to how stuff changes), and dates would be clear so people can see if they find a page stating x that it's immediately clear whether something more recent (y) has superceded it (just recently found a dev relying on information from 2013 about the vapourware known as the HTML5 Outline).

I'm an auditor for my work and have been doing accessicrap since ~2006 or so but I'm always going to be an "enthusiastic amateur". There are very, very few people I would use the term "expert" for and most of them have been spec editors... and as a spec editor I still would not necessarily consider them "experts" on the practical side (what are real authors and real users doing? What is more AT and similar software doing?).

Without something like the judicial-system setup, some decent majority of things like audits are going to be based on opinions without the backup of something like agreed-upon precedence or the arguments (as in a judge's final argument explaining why they ruled the way they did) as a reference beyond "well but we're all pretty sure the spec author *meant* this thing they didn't explicitly say" and other fluffy stuff.

cheers,
_mallory

From: Patrick H. Lauke
Date: Tue, Mar 30 2021 3:53AM
Subject: Re: Judicial system, was The importance of landmarks to screen readers?
← Previous message | Next message →

Just flashing back to the Judge Dredd reference in a11yTO talk...

P
--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Mallory
Date: Tue, Mar 30 2021 5:30AM
Subject: Re: Judicial system, was The importance of landmarks to screen readers?
← Previous message | Next message →

"I AM THE LAAAAAW!"

On Tue, Mar 30, 2021, at 11:53 AM, Patrick H. Lauke wrote:
> Just flashing back to the Judge Dredd reference in a11yTO talk...
>
> P
> --
> Patrick H. Lauke

From: Joe Humbert (A11y)
Date: Tue, Mar 30 2021 6:47AM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

https://github.com/w3c/aria-practices/issues/1469#issuecomment-774730497

Just an FYI. I asked similar questions around complimentary landmarks to the W3C last year via their github.

Thankx,
Joe Humbert, CPWA
Accessibility Champion
Android & iOS Accessibility Novice
Twitter: @joehumbert

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Steve Green
Sent: Tuesday, March 30, 2021 4:41 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] The importance of landmarks to screen readers?

Birkir, everything in the specification contradicts your viewpoint. There are statements that the complementary landmark should be at the top level and there are statements that it is at the same level as the main landmark. There is also a statement that it is related to the main landmark, which only makes sense if it is not inside it. There is not a single aspect of the specification or the examples that supports your view that the complementary landmark can be inside the main landmark. You are relying entirely on the bad drafting of the specification, which omits the word MUST where it is clearly the author's intention.

I profoundly hope that the W3C engage professional standards authors for WCAG 3.0 to avoid this sort of nonsense. It's too important to leave to enthusiastic amateurs. The countless discussions we have had in this forum show that there is a massive problem with ambiguity, errors, omissions and contradictions. I think it's amazing that people have given up so much of their time, presumably unpaid, to write the specifications and examples we have had to date, but it's time to improve the quality.

Steve


-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Birkir R. Gunnarsson
Sent: 30 March 2021 02:25
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] The importance of landmarks to screen readers?

I recommend landmark priarmily when users need to know the beginning and end of the content. Headings onlhy mark the beginning. For users to know where a section labeled by a heading ends, there must be a heading, at the same level or lower, that marks the start of the next independent section of content. This is not always the case, and then you have to either put in a screen reader only heading or use the most appropriate landmark.
And, well spotted Glen, this is why I disagree with the fact that nesting a complementary landmark inside a main landmark is an outright ARIA violation.
I see where they are coming from but I also think there´s a fundamental disconnect between the spec and what works best for users.
If there is, I err on the side of the usability.


On 3/29/21, Peter Weil < = EMAIL ADDRESS REMOVED = > wrote:
> The ARIA Landmark Examples pages do use the word "should". These read
> like a normative document, but they're technically not part of the
> specification (are they?).
>
> " banner, main, complementary and contentinfo landmarks should be top
> level landmarks.
> "complementary landmarks should be top level landmarks (e.g. not
> contained within any other landmarks)."
>
> https://www.w3.org/TR/wai-aria-practices/examples/landmarks/index.html
> https://www.w3.org/TR/wai-aria-practices/examples/landmarks/complement
> ary.html
>
> I don't know what these example pages' exact technical or normative
> status is, but if they incorrectly reflect the spec, that seems like a
> problem. If they do, then the proper usage of complementary landmarks
> seems pretty clear. I wonder whether there is anyone who can tell us
> which of these is true.
> -Peter
>
>
> On 3/29/21, 2:09 PM, "WebAIM-Forum"
> < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>
> Agreed, but it's not a violation if that is not followed. If the spec
> said "Authors MUST (or SHOULD) specify a complementary landmark
> outside the main content...", then *that* would be a violation if not followed.
>
> Like I said, I know my point was nit-picky, but I tend to be pretty
> literal about "violations" of spec only if they go against MUST/SHOULD sections.
>
> On Mon, Mar 29, 2021 at 10:19 AM Steve Green
> < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> The specification also states "The complementary role indicates that
>> contained content is relevant to the main content." That only makes
>> sense if the complementary landmark is outside the main content.
>>
>> Steve
>>
>>
>>
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >


--
Work hard. Have fun. Make history.

From: Jonathan Avila
Date: Tue, Mar 30 2021 9:23AM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

The best place to get an official decision from the Accessibility Guidelines working group on a situation that is not already documented in materials is to log a github issue at: https://github.com/w3c/wcag/issues

This isn't a legal source but it's the best place we have now on what the group that created WCAG has come to consensus on.

Jonathan

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Mallory
Sent: Tuesday, March 30, 2021 4:54 AM
To: Steve Green < = EMAIL ADDRESS REMOVED = >; WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] The importance of landmarks to screen readers?

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


Steve said:
> The countless discussions we have had in this forum show that there is a massive problem with ambiguity, errors, omissions and contradictions.

3.0, from the bits I've seen, does not seem to help with this. With things like "passes alt text at x%" it feels even fuzzier, if that's possible.

I still think, since WCAG is being used as the basis for laws in more and more places (yet is not a judicial document) that maybe the a11y world needs its own "judicial system".

That is, specific instances of something are brought as a "case" to a "judge" and things like rulings can be made on things like "what does the text literally say" or "what is the spirit of this SC" etc. Later cases can refer to earlier cases and they can all be stored in one place where anyone can search to look things up; it would be as flexible as law interpretation (laws interpreted one way may a decade later be interpreted differently due to how stuff changes), and dates would be clear so people can see if they find a page stating x that it's immediately clear whether something more recent (y) has superceded it (just recently found a dev relying on information from 2013 about the vapourware known as the HTML5 Outline).

I'm an auditor for my work and have been doing accessicrap since ~2006 or so but I'm always going to be an "enthusiastic amateur". There are very, very few people I would use the term "expert" for and most of them have been spec editors... and as a spec editor I still would not necessarily consider them "experts" on the practical side (what are real authors and real users doing? What is more AT and similar software doing?).

Without something like the judicial-system setup, some decent majority of things like audits are going to be based on opinions without the backup of something like agreed-upon precedence or the arguments (as in a judge's final argument explaining why they ruled the way they did) as a reference beyond "well but we're all pretty sure the spec author *meant* this thing they didn't explicitly say" and other fluffy stuff.

cheers,
_mallory

From: Peter Weil
Date: Wed, Mar 31 2021 8:45AM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | Next message →

There's also a really good ongoing discussion about this entire issue, with links to related discussions:

https://github.com/w3c/html-aam/issues/86#issue-221936168

It sounds as though they're moving towards restricting mapping <aside> to complementary under certain circumstances (among other things), so that it's not always a landmark. And also allowing <aside> as a landmark within <main>. But the specs, the best practices, the guidelines, the examples, etc., all need to be brought into alignment.

Peter


On 3/30/21, 10:23 AM, "WebAIM-Forum" < = EMAIL ADDRESS REMOVED = > wrote:

The best place to get an official decision from the Accessibility Guidelines working group on a situation that is not already documented in materials is to log a github issue at: https://github.com/w3c/wcag/issues

This isn't a legal source but it's the best place we have now on what the group that created WCAG has come to consensus on.

Jonathan

From: Murphy, Sean
Date: Thu, Apr 01 2021 4:07PM
Subject: Re: The importance of landmarks to screen readers?
← Previous message | No next message

All,

Very interesting discussion. The standards for HTMl5.2 really make some of the different type of sections (regions) such as header, footer and main fairly clear from a document structure view. EG: the main must be a child of the body. While footer and header can be a child of the body or the main. From memory Nav is not so clear. They do provide good guidelines on usage. They do provide code examples as well. I haven't seen any conversation or references related to the standards here. The standards also discuss ARIA usage.

From a practical and user point of view. The average screen reader user on desktop I do not think knows the concept of regions. Thus they don't use them. I would have to double check mobile, but I don't think you can navigate by regions on voiceover or talkback. I have seen web sites which over use landmark regions. Thus the page becomes very noisy for the screen reader user.

The core principle of what a region function is over a header I think is the key to the confusion. I see a region of a means of grouping a common components or information together. If you have 10 product cards for example. Then a <section aria-label="Product cards"> would be a means of assisting the user to understand the structure of the page. Then the headers within the section can break up each product. This is a good usage of a section.

The HTML 5 standards are not the easiest to read and hence, leads to confusion.

Regards
Sean Murphy

Sean Murphy | Senior Digital System specialist (Accessibility)
Telstra Digital Channels | Digital Systems
Mobile: 0405 129 739 | Desk: (02) 9866-7917
Digital Systems Launch Page
Accessibility Single source of Truth

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Peter Weil
Sent: Thursday, 1 April 2021 1:45 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] The importance of landmarks to screen readers?

[External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments.

There's also a really good ongoing discussion about this entire issue, with links to related discussions:

https://github.com/w3c/html-aam/issues/86#issue-221936168

It sounds as though they're moving towards restricting mapping <aside> to complementary under certain circumstances (among other things), so that it's not always a landmark. And also allowing <aside> as a landmark within <main>. But the specs, the best practices, the guidelines, the examples, etc., all need to be brought into alignment.

Peter


On 3/30/21, 10:23 AM, "WebAIM-Forum" < = EMAIL ADDRESS REMOVED = > wrote:

The best place to get an official decision from the Accessibility Guidelines working group on a situation that is not already documented in materials is to log a github issue at: https://github.com/w3c/wcag/issues

This isn't a legal source but it's the best place we have now on what the group that created WCAG has come to consensus on.

Jonathan