{"action":"created","issue":{"url":"https://api.github.com/repos/matatk/landmarks/issues/203","repository_url":"https://api.github.com/repos/matatk/landmarks","labels_url":"https://api.github.com/repos/matatk/landmarks/issues/203/labels{/name}","comments_url":"https://api.github.com/repos/matatk/landmarks/issues/203/comments","events_url":"https://api.github.com/repos/matatk/landmarks/issues/203/events","html_url":"https://github.com/matatk/landmarks/issues/203","id":363848074,"node_id":"MDU6SXNzdWUzNjM4NDgwNzQ=","number":203,"title":"extend Landmarks to include document roles","user":{"login":"TR-SZ","id":43595228,"node_id":"MDQ6VXNlcjQzNTk1MjI4","avatar_url":"https://avatars2.githubusercontent.com/u/43595228?v=4","gravatar_id":"","url":"https://api.github.com/users/TR-SZ","html_url":"https://github.com/TR-SZ","followers_url":"https://api.github.com/users/TR-SZ/followers","following_url":"https://api.github.com/users/TR-SZ/following{/other_user}","gists_url":"https://api.github.com/users/TR-SZ/gists{/gist_id}","starred_url":"https://api.github.com/users/TR-SZ/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/TR-SZ/subscriptions","organizations_url":"https://api.github.com/users/TR-SZ/orgs","repos_url":"https://api.github.com/users/TR-SZ/repos","events_url":"https://api.github.com/users/TR-SZ/events{/privacy}","received_events_url":"https://api.github.com/users/TR-SZ/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-09-26T03:51:55Z","updated_at":"2018-10-08T21:54:40Z","closed_at":null,"author_association":"NONE","body":"Currently, as the name implies, LANDMARK shows only landmark roles. \r\nThere is one document role \"article\" which in my mind is a landmark.\r\nModern 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."},"comment":{"url":"https://api.github.com/repos/matatk/landmarks/issues/comments/427991676","html_url":"https://github.com/matatk/landmarks/issues/203#issuecomment-427991676","issue_url":"https://api.github.com/repos/matatk/landmarks/issues/203","id":427991676,"node_id":"MDEyOklzc3VlQ29tbWVudDQyNzk5MTY3Ng==","user":{"login":"matatk","id":1125522,"node_id":"MDQ6VXNlcjExMjU1MjI=","avatar_url":"https://avatars3.githubusercontent.com/u/1125522?v=4","gravatar_id":"","url":"https://api.github.com/users/matatk","html_url":"https://github.com/matatk","followers_url":"https://api.github.com/users/matatk/followers","following_url":"https://api.github.com/users/matatk/following{/other_user}","gists_url":"https://api.github.com/users/matatk/gists{/gist_id}","starred_url":"https://api.github.com/users/matatk/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/matatk/subscriptions","organizations_url":"https://api.github.com/users/matatk/orgs","repos_url":"https://api.github.com/users/matatk/repos","events_url":"https://api.github.com/users/matatk/events{/privacy}","received_events_url":"https://api.github.com/users/matatk/received_events","type":"User","site_admin":false},"created_at":"2018-10-08T21:54:40Z","updated_at":"2018-10-08T21:54:40Z","author_association":"OWNER","body":"*(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.)*\r\n\r\nThat’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.\r\n\r\nI’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).\r\n\r\n## Landmarks, articles and other assistive technologies\r\n\r\nThis 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.\r\n\r\n*(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.)*\r\n\r\nHowever, 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.\r\n\r\nScott 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.)*\r\n\r\nSome key things to note:\r\n\r\n* 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).\r\n* 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.\r\n* 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 `region`s (`<section>`s) as landmarks).\r\n\r\n## Potential ways to support article navigation\r\n\r\nI 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:\r\n\r\n* **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.\r\n* **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.\r\n\r\nI’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."}}
{"actor":{"display_login":"matatk"}}