E-mail List Archives

Search E-mail List Archives for

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

From: Murphy, Sean
Date: Tue, Apr 21 2020 4:01AM
Subject: Landmarks structures
No previous message | Next message →

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

From: Steve Green
Date: Tue, Apr 21 2020 6:06AM
Subject: Re: Landmarks structures
← Previous message | Next message →

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

From: Jonathan Avila
Date: Tue, Apr 21 2020 8:12AM
Subject: Re: Landmarks structures
← Previous message | Next message →

> 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

From: Birkir R. Gunnarsson
Date: Tue, Apr 21 2020 8:45AM
Subject: Re: Landmarks structures
← Previous message | Next message →

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 ADDRESS 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
>
>

From: Murphy, Sean
Date: Tue, Apr 21 2020 8:34PM
Subject: Re: Landmarks structures
← Previous message | Next message →

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

From: Birkir R. Gunnarsson
Date: Tue, Apr 21 2020 8:42PM
Subject: Re: Landmarks structures
← Previous message | Next message →

<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 ADDRESS 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
>
>

From: Steve Green
Date: Tue, Apr 21 2020 9:27PM
Subject: Re: Landmarks structures
← Previous message | Next message →

My comments are supported by the HTML5 specification, which says "There must not be more than one visible main element in a document. If more than one main element is present in a document, all other instances must be hidden using §5.1 The hidden attribute." There is a fuller explanation at:

https://www.w3.org/TR/html52/grouping-content.html#the-main-element

Steve

From: Murphy, Sean
Date: Tue, Apr 21 2020 11:25PM
Subject: Re: Landmarks structures
← Previous message | Next message →

Steve,


Thanks for this.





Sean Murphy | Digital System specialist (Accessibility)
Telstra Digital Channels | Digital Systems
Mobile: 0405 129 739 | Desk: (02) 9866-7917

From: Mallory
Date: Wed, Apr 22 2020 8:42AM
Subject: Re: Landmarks structures
← Previous message | Next message →

I've mentally had 1.3.6 in mind for (lack of) landmarks, rather than 1.3.1.

cheers,
Mallory

On Wed, Apr 22, 2020, at 7:25 AM, Murphy, Sean wrote:
> Steve,
>
>
> Thanks for this.
>
>
>
>
>
> Sean Murphy | Digital System specialist (Accessibility)
> Telstra Digital Channels | Digital Systems
> Mobile: 0405 129 739 | Desk: (02) 9866-7917
>
>

From: Birkir R. Gunnarsson
Date: Wed, Apr 22 2020 10:33AM
Subject: Re: Landmarks structures
← Previous message | Next message →

Landmarks are mentioned in 2.4.1 as a mechanism to bypass blocks of content.
For 1.3.1, if the region of the page is clear visually, you can argue
this is one of the ways to make this available programmatically (it
could be done with headings or using text. This is if we decide the
visual layout communicates information.
It kind of does but it could also be argued that it doesn't. It
doesn't change the way any elements work but it woud help users locate
functionality, e.g. look for contact info in the footer or search in
the header or focusing right on the main content.


On 4/22/20, Mallory < = EMAIL ADDRESS REMOVED = > wrote:
> I've mentally had 1.3.6 in mind for (lack of) landmarks, rather than 1.3.1.
>
> cheers,
> Mallory
>
> On Wed, Apr 22, 2020, at 7:25 AM, Murphy, Sean wrote:
>> Steve,
>>
>>
>> Thanks for this.
>>
>>
>>
>>
>>
>> Sean Murphy | Digital System specialist (Accessibility)
>> Telstra Digital Channels | Digital Systems
>> Mobile: 0405 129 739 | Desk: (02) 9866-7917
>>
>>

From: L Snider
Date: Thu, Apr 23 2020 6:19PM
Subject: Re: Landmarks structures
← Previous message | No next message

Birkir mentioned the usability study and in my work a minority of
testers used the landmarks, and some had no clue how they worked. In
my experience, people learn how to use their screen readers in very
different ways and how code can help (or can't help their experience),
there is no one size fits all in anything relating to humans.

Cheers

Lisa

On Tue, Apr 21, 2020 at 11:45 AM Birkir R. Gunnarsson
< = EMAIL ADDRESS REMOVED = > wrote:

> 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 ADDRESS 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
> >
> >