Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

extend Landmarks to include document roles #203

Open
TR-SZ opened this Issue Sep 26, 2018 · 8 comments

Comments

Projects
None yet
2 participants
@TR-SZ
Copy link

TR-SZ commented Sep 26, 2018

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

This comment has been minimized.

Copy link
Owner

matatk commented Sep 29, 2018

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

This comment has been minimized.

Copy link
Author

TR-SZ commented Sep 29, 2018

@matatk

This comment has been minimized.

Copy link
Owner

matatk commented Oct 8, 2018

(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

This comment has been minimized.

Copy link
Author

TR-SZ commented Oct 8, 2018

@TR-SZ

This comment has been minimized.

Copy link
Author

TR-SZ commented Oct 9, 2018

@matatk matatk referenced this issue Oct 26, 2018

Open

Headings #156

@matatk

This comment has been minimized.

Copy link
Owner

matatk commented Oct 26, 2018

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.

@matatk matatk self-assigned this Oct 26, 2018

@matatk matatk added the enhancement label Oct 26, 2018

@TR-SZ

This comment has been minimized.

Copy link
Author

TR-SZ commented Oct 31, 2018

@matatk

This comment has been minimized.

Copy link
Owner

matatk commented Nov 1, 2018

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.

@matatk matatk added this to the 3.0.0 milestone Dec 29, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.