WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: The importance of landmarks to screen readers?


From: Birkir R. Gunnarsson
Date: Mar 29, 2021 8:24AM


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 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 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 REMOVED> > On Behalf Of
> Birkir R. Gunnarsson
> Sent: 28 March 2021 16:14
> To: WebAIM Discussion List < <EMAIL 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 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"
>>> 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
>>> 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.