extend Landmarks to include document roles

[TR-SZ]

Currently, as the name implies, LANDMARK shows only landmark roles. There is one document role "article" which in my mind is a landmark. Modern pages use HTML5 <article> tag and while I could code it as a role="region" its role indeed is an article. Being able to show this in Landmarks of the page would be a great advantage, especially if you consider individual <sections> of the article are already visible.

[matatk]

Thanks for your suggestion, particularly for signing up to GitHub in order to make it.

Landmark regions are intended to very broadly signpost the main areas on the page. (In contrast, headings are intended to provide more detailed and fine-grained navigation.) In the case of <section> for example, they’re only counted as landmarks if they’re labelled. This prevents many identical regions showing up and diluting the usefulness of the overview that landmarks provide.

However, <article> elements, whether labelled or not, however, are not considered to be landmarks, as they map, as you mentioned, to the article role, which is not one of the landmark region types. Whilst it may seem counterintuitive that an <article> isn't considered a landmark, but a labelled section is, perhaps this is down to overuse of the <article> element in the wild, or a convention of putting <article> inside <section>, or just trying to ensure there are not too many landmarks on the page, and relying on headings for navigation of the main content.

Whilst I agree that this behaviour may seem odd at first, it’s very important that this extension implements the relevant specifications as closely as possible, so that the results are consistent with other assistive technologies. I think the best course of action would be to find out why the specification is the way it is, which will very likely explain things.

In case this helps: I’m intending to implement heading navigation for this extension.

Happy to keep this open until one or other of us has been able to find out more. I don’t have access to my main machine at the moment, so it will be at least a short while.

[TR-SZ]

Hi Matthew, thank you for taking time and writing back with the explanation.

I am trying to help a company to write "better" web pages.

These days that is a complex mixture of SEO, Accessibility, Analytics and Semantic HTML5, using the semantic tags:article, nav, aside, section, header, footer, figure etc. Many of these tags help accessibility by automatically implied/associated ARIA roles. In fact, I use accessibility and ARIA landmarks to explain "semantic" both to business people and developers alike. Using your plugin I can visually show them how important it is to markup the content and relationship between pieces of the that content in proper tags and add simple aria-labelledby associated with appropriate heading for each region etc. I can demonstrate what is main, and what is a promo (I'm suggesting ASIDE for these). This visualisation is also appealing to the SEO people. Article is where I get stuck. On a busy page with some navigation, banner (header), lots of promos, and somewhere placed a meaningful article(s) it is difficult to explain to people why article is not picked up by your plugin. I could always change its role, but that seems counter intuitive.

I wish there was an alternative plugin to show relationship between semantic web tags and accessibility. I am certain you understand my dilemma here. I am dealing with people where every page starts not with data model but with UX (user experience) followed by VD (visual design) and finally developers render it all as DIVs top to bottom - no semantic tags, no roles, no headings and no accessibility but it looks good.Entire team is trying hard to improve vastly on that, however we are missing out on tools that can help visualise the issue to many people in the organisation to whom web starts in Photoshop.

Regards, Ted

On Sun, 30 Sep 2018 at 08:09, Matthew Tylee Atkinson < notifications@github.com> wrote:

Thanks for your suggestion, particularly for signing up to GitHub in order to make it.

Landmark regions are intended to very broadly signpost the main areas on the page. (In contrast, headings are intended to provide more detailed and fine-grained navigation.) In the case of for example, they’re only counted as landmarks if they’re labelled. This prevents many identical regions showing up and diluting the usefulness of the overview that landmarks provide.

However, elements, whether labelled or not, however, are not considered by the HTML Accessibility API Mappings specification https://www.w3.org/TR/html-aam-1.0/ to be landmarks. Whilst it may seem unusual that an article wouldn’t, but a labelled section is, perhaps this is down to overuse of the element in the wild, or a convention of putting inside , or just trying to ensure there are not too many landmarks on the page, and relying on headings for navigation of the main content.

Whilst I agree that this behaviour may seem odd at first, it’s very important that this extension implements the relevant specifications as closely as possible, so that the results are consistent with other assistive technologies. I think the best course of action would be to find out why the specification is the way it is, which will very likely explain things.

In case this helps: I’m intending to implement heading navigation for this extension.

Happy to keep this open until one or other of us has been able to find out more. I don’t have access to my main machine at the moment, so it will be at least a short while.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/matatk/landmarks/issues/203#issuecomment-425678718, or mute the thread https://github.com/notifications/unsubscribe-auth/Apk13JP3l_LBO6RQO3vyB3ywOJHjM1bfks5uf--mgaJpZM4W52tN .

[matatk]

(I realised my reply had some formatting errors, have updated since; hope it read OK. Also, in case it’s useful info: replies on this thread, whether via email or web, show up on the web archive of the issue’s thread on GitHub, which you can access via the link at the end of the email; they can be edited via the web.)

That’s really interesting hearing how you’re using this extension. I often wonder who’s using it and how, so thanks for letting me know—and for encouraging folk to design stuff accessibly. The techniques you’re teaching sound great.

I’m working on a feature to outline all landmarks at once (#120) and another to allow DOM inspection of landmarks (#170) which may be of interest. In future I’m planning to add heading navigation too (#156).

Landmarks, articles and other assistive technologies

This extension is designed to mirror how other assistive technologies, such as screen readers, would present landmarks to the user. It doesn’t show <article>s as landmarks because, despite being semantic markup, they're not landmark regions per the ARIA and HTML specifications. People who are using most screen-readers would not have <article>s presented to them as landmarks either.

(Aside: <article>s are not landmark regions per the specifications because the <article> element is designed to be self-contained, such that the content of an individual <article> could be viewed in isolation (e.g. via a content syndication service) and still make sense. This makes them more like mini-documents than landmarks within a page.)

However, after doing some research, I did find that most mainstream desktop screen-readers (JAWS, VoiceOver and NVDA, via an add-on) now offer a mode for navigating between articles. This is usually separate from landmark navigation, as article regions are not landmarks, but it works in a similar way: users can move back/forth between articles, or in some cases, bring up a list of articles on the page (in much the same way they can with landmarks). This feature is relatively new, though, and not many users will be aware of it, so it should not be relied upon to provide navigational/structural cues to users. Even when it’s present, the article navigation mode is generally entirely separate to landmark navigation, so you would not necessarily be able to move directly from the main region to a contained <article>, for example: most likely you’d have two separate sets of entities to navigate: landmarks, and articles.

Scott O'Hara does a great job of explaining all of this in his Accessible Landmarks article. (Note: JAWS 2018 has since received the mentioned update that adds article navigation, as distinct to landmark navigation.)

Some key things to note:

• Most users will not be aware of article navigation (in fact I gather even landmark navigation is still fairly new to some novice assistive technology users).
• Most screen-readers that surface <article>s do so separately to landmarks, so there are two different navigation modes, but some include <article>s as if they were landmark regions.
• Some screen-readers count unlabelled <article>s and some only count <article>s that have labels, via aria-label or aria-labelledby attributes (that's similar to how this extension counts only labelled regions (<section>s) as landmarks).

Potential ways to support article navigation

I don’t want to complicate this extension too much, and am already planning to develop heading navigation, which users may want to consider either separate to, or intertwined with, landmark navigation. However, I am now wondering if this extension should provide some sort of <article> navigation as you suggest, given that other assistive technologies support it, in some form or another. There seem to be two main ways to do it:

• Keeping landmark and article navigation separate: this would involve more keyboard shortcuts, and a more complex UI, but would mirror how it generally works in practice, and would ensure that authors who're using this extension don’t fall into the trap of thinking of articles and landmarks as being the same.
• Treating landmark and article navigation as if they were one and the same: this would be simpler to implement and require fewer keyboard shortcuts and would keep the UI simpler, though it wouldn’t necessarily reflect how article navigation works for most people who do use it, and it could lead authors using this extension to create content that relies on navigational features that a number of people won't get to use.

I’m really not sure at this point which seems best, if either—and it’ll be some time before I am able to implement either—but I’ll be thinking about it and trying to find usable ways to express it that honour the spec and how other assistive technologies support them.

[TR-SZ]

Matthew, again a very insightful reply. Thank you.

I'll keep mine to an example for you to contemplate: Imagine a support search results page for a company providing goods and services. For any keyword searched for the system may return multiple complete articles. In this context nothing is

and everything, which is worth reading is contained in

s - many of them.

Yes, my use is not what your extension is intended for - almost a "dev" mode to illustrate the relationship between HTML5 markup, literal content and accessibility. I'm looking forward to the changes you are proposing for your accessibility browser extension.

On Tue, 9 Oct 2018 at 08:54, Matthew Tylee Atkinson < notifications@github.com> wrote:

(I realised my reply had some formatting errors, have updated since; hope it read OK. Also, in case it’s useful info: replies on this thread, whether via email or web, show up on the web archive of the issue’s thread on GitHub, which you can access via the link at the end of the email; they can be edited via the web.)

That’s really interesting hearing how you’re using this extension. I often wonder who’s using it and how, so thanks for letting me know—and for encouraging folk to design stuff accessibly. The techniques you’re teaching sound great.

I’m working on a feature to outline all landmarks at once (#120 https://github.com/matatk/landmarks/issues/120) and another to allow DOM inspection of landmarks (#170 https://github.com/matatk/landmarks/issues/170) which may be of interest. In future I’m planning to add heading navigation too (#156 https://github.com/matatk/landmarks/issues/156). Landmarks, articles and other assistive technologies

This extension is designed to mirror how other assistive technologies, such as screen readers, would present landmarks to the user. It doesn’t show

s as landmarks because, despite being semantic markup, they're not landmark regions per the ARIA and HTML specifications. People who are using most screen-readers would not have

s presented to them as landmarks either.

(Aside:

s are not landmark regions per the specifications because the

element is designed to be self-contained, such that the content of an individual

could be viewed in isolation (e.g. via a content syndication service) and still make sense. This makes them more like mini-documents than landmarks within a page.)

However, after doing some research, I did find that most mainstream desktop screen-readers (JAWS, VoiceOver and NVDA, via an add-on) now offer a mode for navigating between articles. This is usually separate from landmark navigation, as article regions are not landmarks, but it works in a similar way: users can move back/forth between articles, or in some cases, bring up a list of articles on the page (in much the same way they can with landmarks). This feature is relatively new, though, and not many users will be aware of it, so it should not be relied upon to provide navigational/structural cues to users. Even when it’s present, the article navigation mode is generally entirely separate to landmark navigation, so you would not necessarily be able to move directly from the main region to a contained

, for example: most likely you’d have two separate sets of entities to navigate: landmarks, and articles.

Scott O'Hara does a great job of explaining all of this in his Accessible Landmarks https://www.scottohara.me/blog/2018/03/03/landmarks.html article. (Note: JAWS 2018 has since received the mentioned update that adds article navigation, as distinct to landmark navigation.)

Some key things to note:

• Most users will not be aware of article navigation (in fact I gather even landmark navigation is still fairly new to some novice assistive technology users).
• Most screen-readers that surface
  s do so separately to landmarks, so there are two different navigation modes, but some include

  s as if they were landmark regions.
• Some screen-readers count unlabelled
  s and some only count

  s that have labels, via aria-label or aria-labelledby attributes (that's similar to how this extension counts only labelled regions (

  s) as landmarks).

Potential ways to support article navigation

I don’t want to complicate this extension too much, and am already planning to develop heading navigation, which users may want to consider either separate to, or intertwined with, landmark navigation. However, I am now wondering if this extension should provide some sort of

navigation as you suggest, given that other assistive technologies support it, in some form or another. There seem to be two main ways to do it:

• Keeping landmark and article navigation separate: this would involve more keyboard shortcuts, and a more complex UI, but would mirror how it generally works in practice, and would ensure that authors who're using this extension don’t fall into the trap of thinking of articles and landmarks as being the same.
• Treating landmark and article navigation as if they were one and the same: this would be simpler to implement and require fewer keyboard shortcuts and would keep the UI simpler, though it wouldn’t necessarily reflect how article navigation works for most people who do use it, and it could lead authors using this extension to create content that relies on navigational features that a number of people won't get to use.

I’m really not sure at this point which seems best, if either—and it’ll be some time before I am able to implement either—but I’ll be thinking about it and trying to find usable ways to express it that honour the spec and how other assistive technologies support them.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/matatk/landmarks/issues/203#issuecomment-427991676, or mute the thread https://github.com/notifications/unsubscribe-auth/Apk13OoeYHWYDssYA39Iya89KMM_Ze_kks5ui8mhgaJpZM4W52tN .

[TR-SZ]

I am not sure if you are familiar with a couple of UX tools: Wirify: https://www.wirify.com/ and Exit Text: http://brycehanscomb.github.io/exittext/

They create an overlay over original content and create a wire-frame view of it. Imagine if you could use that as an overlay for accessibility roles (perhaps toggling on and off various types of them too: as in landmark, document, composite and widget etc.)

I think the "WORLD" is ready for a tool to demonstrate to business people and developers alike the relationship between the content they create, its HTML markup and accessibility "map" for a better word. Effectively no "map" coverage means no easy access to content for vision vision impaired - this includes people and machines alike (dare I say better SEO)

I see this helping with coding and marking up content to improve document accessibility in a very broad terms, its outline (proper usage of h1 to h6) as well as semantic content grouping or separation, whichever is appropriate for a particular web page.

Your current extension is fine for what it was intended. What I'd like to see is ARIA-Landmarks-Map.

On Tue, 9 Oct 2018 at 09:25, Ted Szukalski szukalski.ted@gmail.com wrote:

Matthew, again a very insightful reply. Thank you.

I'll keep mine to an example for you to contemplate: Imagine a support search results page for a company providing goods and services. For any keyword searched for the system may return multiple complete articles. In this context nothing is

and everything, which is worth reading is contained in

s - many of them.

Yes, my use is not what your extension is intended for - almost a "dev" mode to illustrate the relationship between HTML5 markup, literal content and accessibility. I'm looking forward to the changes you are proposing for your accessibility browser extension.

On Tue, 9 Oct 2018 at 08:54, Matthew Tylee Atkinson < notifications@github.com> wrote:

(I realised my reply had some formatting errors, have updated since; hope it read OK. Also, in case it’s useful info: replies on this thread, whether via email or web, show up on the web archive of the issue’s thread on GitHub, which you can access via the link at the end of the email; they can be edited via the web.)

That’s really interesting hearing how you’re using this extension. I often wonder who’s using it and how, so thanks for letting me know—and for encouraging folk to design stuff accessibly. The techniques you’re teaching sound great.

I’m working on a feature to outline all landmarks at once (#120 https://github.com/matatk/landmarks/issues/120) and another to allow DOM inspection of landmarks (#170 https://github.com/matatk/landmarks/issues/170) which may be of interest. In future I’m planning to add heading navigation too (#156 https://github.com/matatk/landmarks/issues/156). Landmarks, articles and other assistive technologies

This extension is designed to mirror how other assistive technologies, such as screen readers, would present landmarks to the user. It doesn’t show

s as landmarks because, despite being semantic markup, they're not landmark regions per the ARIA and HTML specifications. People who are using most screen-readers would not have

s presented to them as landmarks either.

(Aside:

s are not landmark regions per the specifications because the

element is designed to be self-contained, such that the content of an individual

could be viewed in isolation (e.g. via a content syndication service) and still make sense. This makes them more like mini-documents than landmarks within a page.)

However, after doing some research, I did find that most mainstream desktop screen-readers (JAWS, VoiceOver and NVDA, via an add-on) now offer a mode for navigating between articles. This is usually separate from landmark navigation, as article regions are not landmarks, but it works in a similar way: users can move back/forth between articles, or in some cases, bring up a list of articles on the page (in much the same way they can with landmarks). This feature is relatively new, though, and not many users will be aware of it, so it should not be relied upon to provide navigational/structural cues to users. Even when it’s present, the article navigation mode is generally entirely separate to landmark navigation, so you would not necessarily be able to move directly from the main region to a contained

, for example: most likely you’d have two separate sets of entities to navigate: landmarks, and articles.

Scott O'Hara does a great job of explaining all of this in his Accessible Landmarks https://www.scottohara.me/blog/2018/03/03/landmarks.html article. (Note: JAWS 2018 has since received the mentioned update that adds article navigation, as distinct to landmark navigation.)

Some key things to note:

• Most users will not be aware of article navigation (in fact I gather even landmark navigation is still fairly new to some novice assistive technology users).
• Most screen-readers that surface
  s do so separately to landmarks, so there are two different navigation modes, but some include

  s as if they were landmark regions.
• Some screen-readers count unlabelled
  s and some only count

  s that have labels, via aria-label or aria-labelledby attributes (that's similar to how this extension counts only labelled regions (

  s) as landmarks).

Potential ways to support article navigation

I don’t want to complicate this extension too much, and am already planning to develop heading navigation, which users may want to consider either separate to, or intertwined with, landmark navigation. However, I am now wondering if this extension should provide some sort of

navigation as you suggest, given that other assistive technologies support it, in some form or another. There seem to be two main ways to do it:

• Keeping landmark and article navigation separate: this would involve more keyboard shortcuts, and a more complex UI, but would mirror how it generally works in practice, and would ensure that authors who're using this extension don’t fall into the trap of thinking of articles and landmarks as being the same.
• Treating landmark and article navigation as if they were one and the same: this would be simpler to implement and require fewer keyboard shortcuts and would keep the UI simpler, though it wouldn’t necessarily reflect how article navigation works for most people who do use it, and it could lead authors using this extension to create content that relies on navigational features that a number of people won't get to use.

I’m really not sure at this point which seems best, if either—and it’ll be some time before I am able to implement either—but I’ll be thinking about it and trying to find usable ways to express it that honour the spec and how other assistive technologies support them.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/matatk/landmarks/issues/203#issuecomment-427991676, or mute the thread https://github.com/notifications/unsubscribe-auth/Apk13OoeYHWYDssYA39Iya89KMM_Ze_kks5ui8mhgaJpZM4W52tN .

[matatk]

Thanks for pointing out those two tools; they look interesting and I’ve been able to try them out on some sites to good effect.

Your proposed ‘map’ is a great idea (when #120 is implemented, this extension may go some of the way towards it, and I plan to update that feature with headings and articles as they’re added). However, I gather you’re saying that any element with coverage on the map provides all three of SEO, semantics and accessibility at the same time, and that these three things always go together? Whilst it’s often true, it isn’t guaranteed, because of the way that elements are presented to users (or not) by browsers and by different assistive technologies in practice. I imagine there would be three separate layers to the map, and often they’d coincide, but not always.

Search results example

It’s good to have a more concrete example and your search results is a good one; I think it demonstrates the difference between landmarks and articles well, and leads on to a simpler way to afford navigation in this case. Here are some thoughts and suggestions…

• When talking about the search results page, we could be talking about how the page looks in a browser, visually laid out. As well as presenting search results it would also have a header, probably including some site navigation links, a footer, maybe a sidebar, and probably a form to refine the search.
• These areas of the page would be denoted by landmark regions such as header, nav, search and main. There is definitely main content here: the search results, and probably also the search refinement form. If there wasn’t anything marked up inside a <main> element (or if a “skip link” wasn’t provided to go from the top of the page to the start of the main content) then it would much more laborious and slower for e.g. screen-reader users to get to the content. So there is main content, but that’s “main” in terms of signposting “on this page, there’s an area that contains the search results”—and that’s what landmarks are designed to do.
• The actual search results themselves are marked up in <article> elements, so have an article role, but that’s not so much about signposting where something is on the page; it’s noting that anything in an individual <article> is about a specific thing, and doesn’t depend on anything outside of the <article>. It’s really only intended to be used for whole documents; if each displayed search result is only an abstract of the full article, then, as Scott’s article points out a list should be considered instead. There shouldn’t be many landmarks on the page, as they’re intended to give a broad overview of the page, much as someone looking at the page would innately get. Therefore, if there are many search results, they shouldn’t create oodles of landmark regions, as that makes landmark navigation overwhelming and defeats its purpose.

So far this is sounding rather accessible, as it doesn’t have too many landmark regions, and the search results are marked up semantically appropriately (so they could be syndicated or contribute to SEO). However, we still need a way for the user to skip between search results.

Search results example: suggested navigational cues

Why not just rely on article navigation? For users whose screen-readers (or other assistive technology) provide article navigation: it’s often separate to landmark navigation, for precisely that reason of the disconnect between the intended purpose of the two concepts. That may not be a huge problem, but it means the user has to use that mode of navigation in addition to landmarks, and they may not pick up that there are articles on the page. It’s also not easy to discover, or well-known yet, as it’s new—and because of that, many users won’t have access to it. (And, as above, a list, instead of <article>s, may’ve been more appropriate for the search results if they’re not displayed in full.)

Instead, how about ensuring that each search result <article> has an HTML heading, thus allowing users to navigate by headings? Heading navigation is meant to be fine-grained (in contrast to landmarks) and it has pretty-much always been supported by screen-readers, so it’s widely available, well-understood and quick.

There’s also nothing to stop the <article>s from being labelled via aria-labelledby attributes that point to the visually-apparent headings, so that they can be included in an article list in an understandable way, but I certainly wouldn’t rely on someone having to use article navigation to move around this page, as headings alone (or headings and landmarks) are simpler and should be sufficient.

(Given your interest in and experience with accessibility I imagine you’d already be using headings and probably the aria-labelledby approach too, but I wanted to set it out bit-by-bit to hopefully make the approach clearer.)

All of the above seems both consistent with the intent of the semantics of <article> and landmarks, and headings. However I recognise that in the real world people sometimes use things in unintended ways. We do need to balance “it should be done this way because the spec says so” with “this is how it works in practice”—if all web content authors start using <article>s as landmarks, then I imagine the spec would be updated to reflect that, but from thinking about your example, there are clear benefits to considering them separately.

Plans for this extension

My concern about adding article navigation to this extension was that it could make it seem to content authors like there’s an accessibility benefit to using <article> elements as if they were landmarks, when they’re designed to be different things, and using landmarks and headings (and possibly lists, in this example) is really the way to go.

As above, though, I’m open to adding article navigation, much as I am planning to add heading navigation. There are some practical questions I’m currently thinking about, such as:

• The toolbar button badge currently shows the number of landmarks. Should it also show the number of articles? What about headings?
• How will the GUI represent landmark, heading and article navigation simply? [some ideas in #156]
• Managing keyboard shortcuts (I’ve already been thinking about this for a while and am doing some work on it). [some ideas in #156]
• How to deal with the fact that when article navigation is available, it varies as to whether labelled or unlabelled articles are recognised.
• How to ensure that only the minimum required number of configuration options are added to this extension. [some thoughts in #157]

These are all interesting and fun constraints, and not insurmountable, though it will take a while to get the balance right. I am keen to try to include the three forms of navigation, and your suggestions from your experiences are helpful in shaping how that might happen.

I’m working on releasing 2.4.0 fairly soon, and after that there’s some keyboard-related stuff that would lay some foundations for article navigation (as well as headings) that I’m intending to put in 2.5.0. After that I’ll revisit this thread and see when this may be able to be included.

Thanks again for your input; I'll keep this thread updated with progress, and when I am working on this in future, I can make test versions available to you if you like.

[TR-SZ]

Here are few of my thoughts:

• The toolbar button badge currently shows the number of landmarks. Should it also show the number of articles? What about headings?
  • I think the current button badge works well. It already covers the issue of headings, if the landmark is linked to a heading with aria-labelledby. I actually like this a lot. Often the heading will be quite "far" from the landmark due to many DIV wrappers used by many frameworks / visual design requirements. All of this makes sense if people designing and coding accessible pages actually use tools like yours, it does fail if they don't.
• How will the GUI represent landmark, heading and article navigation simply? [some ideas in #156 https://github.com/matatk/landmarks/issues/156]
  • The "simply" part may indeed be difficult as many of modern pages combine lots of content elements on a single page resulting in a sea of headings. Perhaps if you stick to the current: Landmark:title badge you have a ready solution. Where a heading is present with no wrapping landmark use "undefined | abstract:title" in the badge.
• How to deal with the fact that when article navigation is available, it varies as to whether labelled or unlabeled articles are recognised.
• as per #1: my view is that it should be mandatory to tie a landmark or an article (read any semantic HTML5 element) to its heading and thus there is no difference. Alternatively, you could show headings as children of a landmark / semantic element if there is no aria-labelledby tie.

I have come across something new in last few weeks: Often a page will have a structure:

This presents a challenge for the "NAV" element. The H1, page heading, is placed after the NAV and in order to preserve a good document outline for search engines and by breaking some HTML5 principles the

gets compromised code:

Some navigation title

Some section title

... unordered list of links ...

All of this done to prevent headings to be present before first use of H1. This is where SEO prevails over HTML5 specification and common sense, unfortunately. On Fri, 26 Oct 2018 at 22:40, Matthew Tylee Atkinson < notifications@github.com> wrote: > Thanks for pointing out those two tools; they look interesting and I’ve > been able to try them out on some sites to good effect. > > Your proposed ‘map’ is a great idea (when #120 > is implemented, this > extension may go some of the way towards it, and I plan to update that > feature with headings and articles as they’re added). However, I gather > you’re saying that *any* element with coverage on the map provides all > three of SEO, semantics and accessibility at the same time, and that these > three things *always* go together? Whilst it’s often true, it isn’t > guaranteed, because of the way that elements are presented to users (or > not) by browsers and by different assistive technologies in practice. I > imagine there would be three separate layers to the map, and often they’d > coincide, but not always. > Search results example > > It’s good to have a more concrete example and your search results is a > good one; I think it demonstrates the difference between landmarks and > articles well, and leads on to a simpler way to afford navigation in this > case. Here are some thoughts and suggestions… > > - When talking about the search results page, we could be talking > about how the page looks in a browser, visually laid out. As well as > presenting search results it would also have a header, probably including > some site navigation links, a footer, maybe a sidebar, and probably a form > to refine the search. > - These areas of the page would be denoted by landmark regions such as > header, nav, search and main. There is definitely main content here: > the search results, and probably also the search refinement form. If there > wasn’t anything marked up inside a

element (or if a “skip link” > wasn’t provided to go from the top of the page to the start of the main > content) then it would much more laborious and slower for e.g. > screen-reader users to get to the content. So there is main content, > but that’s “main” in terms of signposting “on this page, there’s an area > that contains the search results”—and that’s what landmarks are designed to > do. > - The actual search results themselves are marked up in

> elements, so have an article role, but that’s not so much about > signposting where something is on the *page*; it’s noting that > anything in an individual

is about a specific thing, and > doesn’t depend on anything outside of the

. It’s really only > intended to be used for whole documents; if each displayed search result is > only an abstract of the full article, then, as Scott’s article points out a > list should be considered instead > . > There shouldn’t be many landmarks on the page, as they’re intended to give > a broad overview of the page, much as someone looking at the page would > innately get. Therefore, if there are many search results, they shouldn’t > create oodles of landmark regions, as that makes landmark navigation > overwhelming and defeats its purpose. > > So far this is sounding rather accessible, as it doesn’t have too many > landmark regions, and the search results are marked up semantically > appropriately (so they could be syndicated or contribute to SEO). However, > we still need a way for the user to skip between search results. > Search results example: suggested navigational cues > > Why not just rely on article navigation? For users whose screen-readers > (or other assistive technology) provide article navigation: it’s often > separate to landmark navigation, for precisely that reason of the > disconnect between the intended purpose of the two concepts. That may not > be a huge problem, but it means the user has to use that mode of navigation > in addition to landmarks, and they may not pick up that there are articles > on the page. It’s also not easy to discover, or well-known yet, as it’s > new—and because of that, many users won’t have access to it. (And, as > above, a list, instead of

s, may’ve been more appropriate for > the search results if they’re not displayed in full.) > > Instead, how about ensuring that each search result

has an HTML > heading, thus allowing users to navigate by headings? Heading navigation > *is* meant to be fine-grained (in contrast to landmarks) and it has > pretty-much always been supported by screen-readers, so it’s widely > available, well-understood and quick. > > There’s also nothing to stop the

s from being labelled via > aria-labelledby attributes that point to the visually-apparent headings, > so that they *can* be included in an article list in an understandable > way, but I certainly wouldn’t rely on someone having to use article > navigation to move around this page, as headings alone (or headings and > landmarks) are simpler and should be sufficient. > > *(Given your interest in and experience with accessibility I imagine you’d > already be using headings and probably the aria-labelledby approach too, > but I wanted to set it out bit-by-bit to hopefully make the approach > clearer.)* > > All of the above seems both consistent with the intent of the semantics of >

and landmarks, and headings. However I recognise that in the > real world people sometimes use things in unintended ways. We do need to > balance “it should be done this way because the spec says so” with “this is > how it works in practice”—if all web content authors start using

s > as landmarks, then I imagine the spec would be updated to reflect that, but > from thinking about your example, there are clear benefits to considering > them separately. > Plans for this extension > > My concern about adding article navigation to this extension was that it > could make it seem to content authors like there’s an accessibility benefit > to using

elements as if they were landmarks, when they’re > designed to be different things, and using landmarks and headings (and > possibly lists, in this example) is really the way to go. > > As above, though, I’m open to adding article navigation, much as I am > planning to add heading navigation. There are some practical questions I’m > currently thinking about, such as: > > - The toolbar button badge currently shows the number of landmarks. > Should it also show the number of articles? What about headings? > - How will the GUI represent landmark, heading and article navigation > simply? [some ideas in #156 > ] > - Managing keyboard shortcuts (I’ve already been thinking about this > for a while and am doing some work on it). [some ideas in #156 > ] > - How to deal with the fact that when article navigation is available, > it varies as to whether labelled or unlabelled articles are recognised. > - How to ensure that only the minimum required number of configuration > options are added to this extension. [some thoughts in #157 > ] > > These are all interesting and fun constraints, and not insurmountable, > though it will take a while to get the balance right. I am keen to try to > include the three forms of navigation, and your suggestions from your > experiences are helpful in shaping how that might happen. > > I’m working on releasing 2.4.0 fairly soon, and after that there’s some > keyboard-related stuff that would lay some foundations for article > navigation (as well as headings) that I’m intending to put in 2.5.0. After > that I’ll revisit this thread and see when this may be able to be included. > > Thanks again for your input; I'll keep this thread updated with progress, > and when I am working on this in future, I can make test versions available > to you if you like. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > , > or mute the thread > > . >

[matatk]

Thanks for your thoughts. Your example highlights how variable things can be on the web, and has prompted me to think more about handling of headings. It's quite a fun challenge trying to come up with a system for displaying things, when the things might come in a completely different order to that which is expected.