E-mail List Archives
Thread: Does SC1.3.1 require landmarks?
Number of posts in this thread: 7 (In chronological order)
From: Guy Hickling
Date: Sun, Oct 11 2020 2:13PM
Subject: Does SC1.3.1 require landmarks?
No previous message | Next message →
The "Bypass blocks for a small website" thread on this forum has wandered
off on to other topics as well. So to simplify things I'm starting this new
thread on one of those topics to take it a bit further - the discussion
about whether SC1.3.1 requires landmarks.
SC1.3.1 says "....structure, and relationships conveyed through
presentation...". Almost all web pages are clearly presented in the form of
a page header at the top, with the main. usually unique content of the page
below that. And the majority of websites usually have a page footer as well.
If we look more closely at the contents of those areas, we almost
invariably find the the header consists largely of navigation and maybe
also website settings or other things to do with the site as a whole, while
the area underneath, as we all know if we have used the internet for more
than 5 minutes, has content specially for that page.
If we are in any doubt, on a particular website, as to whether the stuff at
the top is a header or not we only have to go to another page on the site
to see if it is a common header showing on other pages of the site as well.
So that is the presentation - a header, an area of unique content for the
page, and maybe a footer as well. Given that, SC1.3.1 says, either that
presentation must be conveyed programmatically, or by text.
I think the only way of conveying that in HTML is using the header, main
and footer elements. Or in ARIA we can use roles (though deprecated by the
first rule of ARIA in favour of using the HTML elements).
So I suggest, yes, SC1.3.1 does require either the use of the landmark
elements or roles, or the use of texts instead to identify those areas.
(But just adding texts would obviously not be a very sensible solution, and
be more effort for developers as well, so basically we end up using
landmarks).
Does that reasoning make sense?
I often use a similar reasoning whenever I'm in doubt as to whether
something is covered by 1.3.1 or not. Given that 1.3.1 is so vague it
doesn't actually specify any particular target construct at all in the
normative wording!
So I ask myself "is this a structure or relationship that is conveyed
visually (or even otherwise) to users?" If it is, then I report it as an
issue if it is not also conveyed either programmatically or by text.
Regards,
Guy Hickling
Accessibility Consultant
From: Patrick H. Lauke
Date: Sun, Oct 11 2020 2:33PM
Subject: Re: Does SC1.3.1 require landmarks?
← Previous message | Next message →
On 11/10/2020 21:13, Guy Hickling wrote:
[...]
> So I suggest, yes, SC1.3.1 does require either the use of the landmark
> elements or roles, or the use of texts instead to identify those areas.
> (But just adding texts would obviously not be a very sensible solution, and
> be more effort for developers as well, so basically we end up using
> landmarks).
Saying that a site that does not use landmark elements/roles fails 1.3.1
would, in essence, make 90% of the web as it exists today
invalid/failing ... so I'm not sure it's quite as cut-and-dry (though
others have argued for this exact interpretation in the past).
I'd suggest that AT users can usually also infer different sections
purely from the order in which they appear in the content. Otherwise, we
could take this to a further extreme and say any time something like a
<div> is present (and styled to appear as a box, or simply styled in a
way that it's somehow self-contained/apart), it would fail if it didn't
somehow convey this structurally (and since a humble `<div>` doesn't get
announced, it would require something else like a role="group" and an
accessible name, or similar).
In general, rather than saying outright (in essence) if a site doesn't
use landmark elements/roles it fails, it's more about "is the page
understandable as is", and being a bit more pragmatic (while suggesting
as a best practice that yes, if possible, authors should consider using
landmarks).
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: Patrick H. Lauke
Date: Sun, Oct 11 2020 2:55PM
Subject: Re: Does SC1.3.1 require landmarks?
← Previous message | Next message →
See also previous discussion here https://github.com/w3c/wcag/issues/340
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: wolfgang.berndorfer@zweiterblick.at
Date: Mon, Oct 12 2020 12:03PM
Subject: Re: Does SC1.3.1 require landmarks?
← Previous message | Next message →
Seems, the discussion on GitHub in 2017 was near to include a
failure/technique for landmarks... Or some hoped that WCAG 2.1 would include
a new SC for them.
And some arguments against it seem strange to me.
"we cannot retroactively introduce conditions that invalidates content that
previously met the SC conformance ."
I thought, the SC were open for future technologies and techniques.
"The reason we were given for not including this failure in WCAG 2.0 was
that it would make legacy content fail (2008 and before). [.] it is intended
to apply to WCAG 2.1 to new sites that want to meet the new standard."
Anyway. There is no place for landmarks in the ontology of the WCAG 2.1
either, as it seems. But everyone regards them as best practice.
Only the WebAIM checklist for 1.3.1 places landmarks beside headings and
lists:
https://webaim.org/standards/wcag/checklist#sc1.3.1
So, what should I do? Check or not? Recommend only as best practice?
Wolfgang
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
Patrick H. Lauke
Sent: Sunday, October 11, 2020 10:55 PM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] Does SC1.3.1 require landmarks?
See also previous discussion here https://github.com/w3c/wcag/issues/340
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
http://webaim.org/discussion/archives
From: Patrick H. Lauke
Date: Mon, Oct 12 2020 1:00PM
Subject: Re: Does SC1.3.1 require landmarks?
← Previous message | Next message →
On 12/10/2020 19:03, = EMAIL ADDRESS REMOVED = wrote:
[...]
> So, what should I do? Check or not? Recommend only as best practice?
It's the usual "it depends" with WCAG, as 1.3.1 has many subjective
aspects (as most other SCs). Is the user likely not to understand the
page/content without those landmarks/regions/structures which are
visually evident also being explicitly marked up?
In my view, anyway...
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: Guy Hickling
Date: Mon, Oct 12 2020 8:05PM
Subject: Re: Does SC1.3.1 require landmarks?
← Previous message | Next message →
Thank you Patrick, for that reference to the previous conversation. (For
the record, several people were recommending that not using the landmark
elements should be made into a Fail technique. So a very interesting
reference indeed.)
Reading through that conversation, the main reason the suggestion was
turned down then was because people felt that making a Fail technique out
of it would attempt to change the nature or meaning of SC 1.3.1.
I don't think I agree with that argument, because the SC says what it says,
and would remain saying that regardless of the techniques suggested for it.
It does not single out any particular element or construct. The SC says
simply, "structure, and relationships conveyed through presentation".
In that regard websites have not changed in presentation of headers, main
content and footers since WCAG 2.0 was released in 2008. Most web pages
then had a header and a main content area visually, and usually a footer as
well, and they still do. Nothing has changed there. Since the SC is about
the presentation of the page, nothing we say about the use of particular
HTML elements will affect the SC's meaning.
What has changed is our attitude to those page areas. The HTML landmark
elements didn't even exist then (except possibly as a very early draft),
and we didn't think then in terms of defining the areas of a page. We now
accept as an accessibility matter that the header, main, footer and other
landmark elements should be used where appropriate (or the ARIA landmark
roles if necessary).
If, for the sake of argument, we accept that 1.3.1 does say we should
identify landmark areas where appropriate, then we should have followed it
in 2008. Just because we didn't do that doesn't mean the SC wasn't telling
us to do so, and therefore doesn't mean we are trying to change the meaning
of the SC by accepting we should do so now. It just means we have been
somewhat belated in our recognition of the need.
(BTW: Since the HTML elements didn't exist when WCAG 2.0 came out, so we
would have to have used the 1.3.1 alternative, of saying it in text -
probably one of the reasons it didn't occur to us then!)
What I also think is an issue, is that we have a Technique for using the
ARIA landmark roles, but don't seem to have an HTML Technique for the
equivalent HTML elements. If we have one we should have the other.
One other argument raised in the above mentioned conversation is that it is
not always obvious, on some websites, whether there is a clearly presented
header or footer or main area. But that is true of other things. It often
isn't always obvious whether some "headings" are really headings or not.
Sometimes it comes down to a matter of opinion. Other SCs meet similar
vagueness in content, and some SCs are themselves as vague as 1.3.1. I
would say, for all vague cases, if it isn't clear then we don't have to
raise it as a WCAG failure.
To me, then,
1) SC1.3.1 clearly says "structure, and relationships conveyed through
presentation" must also be conveyed programmatically (or by text).
2) Most websites clearly present a header and a main content area.
3) So 1.3.1 mandates the landmarks at least as strongly as it mandates the
heading elements!
From: Patrick H. Lauke
Date: Tue, Oct 13 2020 12:11AM
Subject: Re: Does SC1.3.1 require landmarks?
← Previous message | No next message
On 13/10/2020 03:05, Guy Hickling wrote:
[...]
> What I also think is an issue, is that we have a Technique for using the
> ARIA landmark roles, but don't seem to have an HTML Technique for the
> equivalent HTML elements. If we have one we should have the other.
Keeping in mind that positive techniques are not mandatory, i.e. you
don't fail because you're not using a positive technique.
> One other argument raised in the above mentioned conversation is that it is
> not always obvious, on some websites, whether there is a clearly presented
> header or footer or main area. But that is true of other things. It often
> isn't always obvious whether some "headings" are really headings or not.
> Sometimes it comes down to a matter of opinion. Other SCs meet similar
> vagueness in content, and some SCs are themselves as vague as 1.3.1. I
> would say, for all vague cases, if it isn't clear then we don't have to
> raise it as a WCAG failure.
>
> To me, then,
> 1) SC1.3.1 clearly says "structure, and relationships conveyed through
> presentation" must also be conveyed programmatically (or by text).
> 2) Most websites clearly present a header and a main content area.
> 3) So 1.3.1 mandates the landmarks at least as strongly as it mandates the
> heading elements!
If you now want to go around failing a site for not using
<header>/<footer>, that's your prerogative. But not everybody doing
audits will agree with your draconian approach. There are many things
site should do that, if not done, have a massive impact on users with
disabilities and deserve a hard fail. Not using <header>/<footer> is, at
best, a technical failure in my book.
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