WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Landmarks structures

for

From: Mallory
Date: Apr 22, 2020 8:42AM

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
>
> -----Original Message-----
> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
> Steve Green
> Sent: Wednesday, 22 April 2020 1:27 PM
> 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.
>
> 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
>
>
> -----Original Message-----
> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
> Birkir R. Gunnarsson
> Sent: 22 April 2020 03:43
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Landmarks structures
>
> <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.
> > > > > > 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
> > > > > >