WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Landmarks structures

for

From: Birkir R. Gunnarsson
Date: Apr 21, 2020 8:42PM


<header> and <footer> elements map to banner/contentinfo roles when
they are children of the <body> element.
If, however, they are used inside <article> or <section> elements they
should not map to those landmarks, they mark the header/footer of that
region/article.
This definition is not consistent with how some screen readers treat
them, which is confusing.
I fail to grasp the argument for multiple or nested banner and
contentinfo landmarks on pages, the banner represents the page header,
contentinfo the page footer, there should only be one.
Yes, you could have a page with nested pages (e.g. iframes and such),,
particularly in crazy web design like social media sites, but I won't
allow it for standard pages and make sure it gets called out as a
fail.
For landmarks to be useful they need to be used systematically,
consistently and sparingly.
The <main> element does not count as a structural element in HTML5, I
can't remember why, but I had to look all over the HTML5 spec to find
it.


On 4/21/20, Murphy, Sean < <EMAIL REMOVED> > wrote:
> I agree with the statement of screen reader users not knowing how to
> navigate web pages effectively. Is it training or people getting used to how
> to do something and don't explore a different way, or not understanding the
> terminology being used. As this does get confusing for some.
>
> What I am struggling with is code testing tools like Ark and Axe reporting
> the use of nested banners (headers) and footers, Navs etc as failures based
> upon best practise. This W3C document which I am not sure is the latest
> version https://www.w3.org/TR/html53/sections.html does not indicate this at
> all. All the examples I have reviewed contained in the document supports the
> use of headers and navs inside articles and asides. I did not see any
> mention about the main section which supports Steev's comments. So I am
> wondering if this is the formal release of the HTMl 5 specs and how people
> came up with the best practise?
>
> Note: The document does mention sections become regions if you apply
> aria-label in an indirect way. The use of aria-label on article does not
> change it into a region from reading the above document.
>
>
>
>
> Sean Murphy | Digital System specialist (Accessibility)
> Telstra Digital Channels | Digital Systems
> Mobile: 0405 129 739 | Desk: (02) 9866-7917
>
> -----Original Message-----
> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
> Birkir R. Gunnarsson
> Sent: Wednesday, 22 April 2020 12:46 AM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Landmarks structures
>
> [External Email] This email was sent from outside the organisation – be
> cautious, particularly with links and attachments.
>
> I think the region landmark (role="region" and the <section> element) only
> turn into landmarks when you provide an accessible name (using aria-label or
> aria-labelledby), same probably applies to <article> and the article role,
> though I admit I am too lazy to check (well, too busy to be honest).
> I try to require that header/main/footer be identified as landmarks when
> they are clearly identified visually on the page.
> I recommend regions when a section of content is not followed by a header,
> e.g. content that is displayed/hidden in an accordion. Often the content
> after the accordion does not start with a heading and without a region with
> an aria-label you cannot easily tell where the expanded content ends and the
> next block of content begins, not unless you collapse the content and then
> check.
> The main advantage of landmarks is that their boundries (start and
> end) are announced, a heading only marks the start of a section of content,
> not the end of it.
> If you have multiple landmarks of the same type, like multiple nav or region
> landmrks, you should supply an accessible name for each so users can easily
> tell them apart.
> I recommend navigation landmarks for navigation menus.
> Imagine a website header with a set of accordions, e.g.
> <button aria-expanded="true">Mortgage solutions</button> <nav
> aria-label="mortgage solutions"> list of mortgage solutions links goes here
> </nav>
>
> In our usability testing we found that, out of over 10 screen reader users,
> not a single one used a landmark and basically no users knew what a landmark
> was. I find this shocking and bit sad, shows lack of training or
> documentation of what could be a very useful feature.
>
>
> On 4/21/20, Jonathan Avila < <EMAIL REMOVED> > wrote:
>>> 1.3.1 basically says that if you can visually perceive a relationship
>>> between components, then that relationship must also be conveyed
>>> programmatically. In most cases when you look at a website you can
>>> clearly see the page header and footer, which are common to all
>>> pages. Those groupings must be conveyed programmatically. Everything
>>> in between them would usually be the main content, so that should be
>>> in a main landmark. I would therefore say that the absence of landmarks
>>> is a failure of 1.3.1.
>>
>> At this point there is not a documented WCAG blanket failure for lack
>> of landmarks as some people have argued that use of headings within a
>> document does communicate and create distinction for the sections of
>> pages that can provide equivalents (e.g. h1 for the start of main
>> content). Text can also be used to meet criterion 1.3.1. So any
>> determination would likely need to take into account the text that is
>> used along with other structures like headings to determine if visual
>> backgrounds, etc. have equivalents. Keep in mind that some pages have
>> no visual distinction between headers and footers and main content.
>>
>> Jonathan
>>
>> -----Original Message-----
>> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
>> Steve Green
>> Sent: Tuesday, April 21, 2020 8:07 AM
>> To: WebAIM Discussion List < <EMAIL REMOVED> >
>> Subject: Re: [WebAIM] Landmarks structures
>>
>> 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.
>>
>>
>> 1.3.1 basically says that if you can visually perceive a relationship
>> between components, then that relationship must also be conveyed
>> programmatically. In most cases when you look at a website you can
>> clearly see the page header and footer, which are common to all pages.
>> Those groupings must be conveyed programmatically. Everything in
>> between them would usually be the main content, so that should be in a
>> main landmark. I would therefore say that the absence of landmarks is a
>> failure of 1.3.1.
>>
>> The HTML5 specification states how many of each landmark you can have
>> and how they can be nested. You can only have one main landmark that
>> is visible, although you can have others that are hidden. You can have
>> as many headers and footers as you want.
>>
>> It's fine to nest landmarks as long as you do so in accordance with
>> the
>> HTML5 specification. You can have navigation and search landmarks
>> inside pretty much any other landmark, but you can't put the main
>> landmark inside anything else. As far as I can tell, you can even have
>> one navigation landmark inside another.
>>
>> There are obviously a vast number of permutations, so you can't learn
>> them all - you need to understand the principles. I couldn't find them
>> all gathered in one place, so it looks like you need to look at the
>> specification for each one separately.
>>
>> Steve Green
>> Managing Director
>> Test Partners Ltd
>>
>>
>> -----Original Message-----
>> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
>> Murphy, Sean
>> Sent: 21 April 2020 11:01
>> To: WebAIM Discussion List < <EMAIL REMOVED> >
>> Subject: [WebAIM] Landmarks structures
>>
>> All,
>>
>> I have been doing some research for landmarks and want to get some
>> clarification.
>>
>> 1. If no landmarks are present, is this technically a 1.3.1
>> failure? If so, what technique / failure does this relate to? As I
>> could not identify one.
>> 2. I have seen multiple posts and even Axe refers to only having
>> one header (banner), content-info (footer), main, aside, etc on a
>> page. Is this documented anywhere? As I read in a W3C tutorial stating
>> you could have multiple banners for example in one of their tutorials. An
>> example blog:
>> https://keithjgrant.com/posts/2018/03/html5-sectioning-and-landmark-elements/
>> 3. Is it bad practise to have nested regions? I can understand the
>> practise of only having one header, footer, main, etc on a page.
>>
>>
>> Base upon the W3C page https://www.w3.org/TR/html53/sections.html
>> Using an aria-label will <H#> is suggested to be used instead of
>> aria-label because this will change it to a region. This is not
>> clearly spelled out in the W3C document.Other blogs do mention this.
>> Extract from this document about labelling a section:
>>
>> "Assistive Technology may convey the semantics of the
>> section<https://www.w3.org/TR/html53/sections.html#elementdef-section>
>> to users when the element has an explicit label. This information can
>> provide a hint to users as to the type of content. For example the
>> role of the element, which in this case is "region", can be announced
>> by screen reader software when a user navigates to an
>> section<https://www.w3.org/TR/html53/sections.html#elementdef-section>
>> element. User Agents may also provide methods to navigate to
>> section<https://www.w3.org/TR/html53/sections.html#elementdef-section>
>> elements.".
>>
>> The W3C above document does not mention you cannot nest Nav's, is this
>> correct or not?
>>
>> I wish to understand the nesting rules for regions.
>>
>> Sean document
>>
>> Sean Murphy | Digital System specialist (Accessibility) Telstra
>> Digital Channels | Digital Systems
>> Mobile: 0405 129 739 | Desk: (02) 9866-7917
>>
>> >> >> 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.