Open Bug 670928 Opened 14 years ago Updated 2 years ago

HTML5 element and WAI-ARIA landmark roles easily navigable in Firefox

Categories

(Firefox :: Disability Access, enhancement)

Product:
Firefox
Component:
Disability Access
Version:
5 Branch
Platform:
All
Other
Type:
enhancement

Tracking

()

Status:
REOPENED

People

(Reporter: philipp.naderer, Assigned: eeejay)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

ff-outline-view.png
14.31 KB, image/png
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 Build ID: 20110413222027 Steps to reproduce: We added WAI-ARIA landmarks to different sites. Screen readers get them without any problems from the accessibility API. But there is no way to access them in Firefox via a shortcut or in the toolbar. Providing accesskey attributes on skiplinks pointing to the landmarks is the only way to access the landmarks to users with limited motor skills. Actual results: No way to access a landmark overview in Firefox. Expected results: Add a shortcut which opens a window displaying all the landmark regions and makes them accessible for limited motor skills users.
It makes sense to prototype this as extension and get feedback from community. Additionally it could expose hot keys to navigate by landmarks as screen readers do. Guys, what do you think?
Status: UNCONFIRMED → NEW
Ever confirmed: true
I agree, this is something that can be started as an extension and then maybe folded into the Firefox main distribution later.
Marco, could think of UI (in terms of features) based on your experience with screen readers?
Screen readers offer two ways to navigate: 1. They have a specific shortcut (d with NVDA, for example), to navigate from landmark to landmark in their virtual buffers. Shift+D in NVDA takes you backwards through the landmarks. Second, they offer a list of landmarks. If you press NVDA+F7 (that's the NumPad 0 held down, and then F7 in NVDA), you get alist of items. Links is selected by default, but NVDA offers two other choices: Headings and Landmarks. When landmarks is chosen, you get a tree of landmarks, so you can even see if landmarks are in nested elements. You can choose one with the arrow keys and press Enter, and virtual cursor is taken to that position in the virtual document. Apple with VoiceOver offer similar things: One of the rotor settings is navigation by landmarks, and the list of items (VO+U) also offers landmarks as one of the choices. So the least this extension should do is offer these two means: 1. a keyboard shortcut that would take the keyboard focus and move it to the element or closest to the element that the landmark is on (these aren't necessarily tabbable), and second a list of landmarks to give an overview what's available.
Thank you, Marco. David, do you keep in mind anybody who could prototype? This could be a nice project.
It seems this needs to be fixed for UUAG. David, what's the status?
Blocks: 321632
Maybe we should add UI to the Quick Find bar?! (The one brought up by hitting '/')
Adding ui-wanted keyword for input on comment 9.
Keywords: uiwanted
I also want to understand the intended difference between Quick Find and Find bars. This probably belongs on the Find bar, or maybe we want a proper nav bar?
Summary: WAI-ARIA landmark roles not accessible directly in Firefox → HTML5 element and WAI-ARIA landmark roles easily navigable in Firefox
Adding the ability to find landmarks in Firefox sounds like a great idea, but I think it's really best as an extension. There isn't going to be a lot of demand for outside of users with screenreaders. (In reply to David Bolter [:davidb] from comment #11) > I also want to understand the intended difference between Quick Find and > Find bars. This probably belongs on the Find bar, or maybe we want a proper > nav bar? As I understand it, the only difference is that quick find disappears when you target away from it, and regular find in page stays. If there's actual, legitimate reason to have both of these, I'll eat my hat and post the video to YouTube.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
(In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #12) > Adding the ability to find landmarks in Firefox sounds like a great idea, > but I think it's really best as an extension. There isn't going to be a lot > of demand for outside of users with screenreaders. I do wonder about small devices where cycling through <article> elements might be handy, but I imagine we're running out of gestures. Thanks for the feedback.
(In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #12) > Adding the ability to find landmarks in Firefox sounds like a great idea, > but I think it's really best as an extension. There isn't going to be a lot > of demand for outside of users with screenreaders. The problem does not apply for users with screenreaders. They get the landmarks via the accessibilty APIs from their software. But I met a guy who uses a small stick in his mouth to press buttons on the keyboard - his only "assistive technology". If there are accesskey-attributes he is pretty fast with this method. But more web sites drop accesskeys and replace them with ARIA landmark roles. This works fine for screenreader users, but this guy now has to a) install a screenreader he doesn't need or b) tab through the whole page. I agree that an extension for that special needs would be okay and easier to implement than a build-in solution.
This is related to bug 698823, where we introduce an in-browser virtual cursor that uses a11y rules to navigate a document.
Boriss, after consideration we'd like to keep this on the radar, so I am reopening and assigning to Eitan. We have a nice idea that will use Eitan's traversal work. We may end up with an extension or something default preffed off in product. We'll be sure to loop back. (If the bug is causing clutter - you can reassign to core/Disability Access APIs)
Assignee: nobody → eitan
Severity: normal → enhancement
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Now that we have an in-browser virtual cursor writing some javascript that would introduce this functionality would be trivial. It should first be demonstrated as an extension, and maybe later added as a feature in the core product. The one non-trivial bit is introducing virtual cursor to the platform APIs so that screen readers could pick up changes and locations. In AT-SPI, I could see this being active descendants.
(In reply to Eitan Isaacson [:eeejay] from comment #17) > Now that we have an in-browser virtual cursor writing some javascript that > would introduce this functionality would be trivial. It should first be > demonstrated as an extension, and maybe later added as a feature in the core > product. I'm concerned that will cause us to activate accessibility in a lot of cases where we don't now. I also don't see why the dom tree walker wouldn't be enough here. > The one non-trivial bit is introducing virtual cursor to the platform APIs > so that screen readers could pick up changes and locations. In AT-SPI, I > could see this being active descendants. why? my understanding of the bug would involve the navigated to landmark being focused which we of course already expose.
(In reply to Trevor Saunders (:tbsaunde) from comment #18) > (In reply to Eitan Isaacson [:eeejay] from comment #17) > > Now that we have an in-browser virtual cursor writing some javascript that > > would introduce this functionality would be trivial. It should first be > > demonstrated as an extension, and maybe later added as a feature in the core > > product. > > I'm concerned that will cause us to activate accessibility in a lot of cases > where we don't now. I also don't see why the dom tree walker wouldn't be > enough here. > This would consists of two bits: 1. A keyboard event listener that would consume a predefined key combo and would retrieve the virtual cursor from the tab document and move it. Accessibility does not need to be activated before that. 2. An event listener for visual indication, it won't activate accessibility. > > The one non-trivial bit is introducing virtual cursor to the platform APIs > > so that screen readers could pick up changes and locations. In AT-SPI, I > > could see this being active descendants. > > why? my understanding of the bug would involve the navigated to landmark > being focused which we of course already expose. Arbitrary elements like landmark containers are not focusable. Let's say we do it with your approach, just walk the DOM - once you land on a landmark element what do you do? How do you get a desktop screen reader to read that section? You need to fire an event that screen readers could consume that is outside of the usual focusable/focused and selectable/selected paradigm. That is what the virtual cursor API could provide.
(In reply to Eitan Isaacson [:eeejay] from comment #19) > (In reply to Trevor Saunders (:tbsaunde) from comment #18) > > (In reply to Eitan Isaacson [:eeejay] from comment #17) > > > Now that we have an in-browser virtual cursor writing some javascript that > > > would introduce this functionality would be trivial. It should first be > > > demonstrated as an extension, and maybe later added as a feature in the core > > > product. > > > > I'm concerned that will cause us to activate accessibility in a lot of cases > > where we don't now. I also don't see why the dom tree walker wouldn't be > > enough here. > > > > This would consists of two bits: > 1. A keyboard event listener that would consume a predefined key combo and > would retrieve the virtual cursor from the tab document and move it. > Accessibility does not need to be activated before that. I was assuming it would only force a11y on lazily, but it will still mean anyone who uses the feature will have a11y on when they don't really need it. > 2. An event listener for visual indication, it won't activate accessibility. what event are you talking about here that doesn't assume a11y is on? > > > The one non-trivial bit is introducing virtual cursor to the platform APIs > > > so that screen readers could pick up changes and locations. In AT-SPI, I > > > could see this being active descendants. > > > > why? my understanding of the bug would involve the navigated to landmark > > being focused which we of course already expose. > > Arbitrary elements like landmark containers are not focusable. well, not necessarily focusable, but that's a problem that you don't really solve either since its not really clear what it means to navigate to something that isn't focusable. > Let's say we do it with your approach, just walk the DOM - once you land on > a landmark element what do you do? How do you get a desktop screen reader to > read that section? You need to fire an event that screen readers could > consume that is outside of the usual focusable/focused and > selectable/selected paradigm. That is what the virtual cursor API could > provide. As I understand the bug the main case of interest is the case without a screen reader. However once we have some way of doing the navigation we do need to think about this problem if the solution to the navigation problem isn't solved in such a way that it already works. btw I'm not totally convinced that we can't use focused since focused is defined to be the thing with keyboard focus and if it doesn't have keyboard focus for some value of focus I'm not sure what it means that you 'navigated" to it.
CC+ Neil Deakin. We don't want to instantiate the a11y engine, but we want a way to 'move' keyboard context (in the keyboard nav sense) to the landmark. I'm not sure of what we call this. It is like what happens when you 'click' or 'select' some text and hit tab... I think the tab nav picks up from that point. In this case we want to move that point to the landmark. Neil can you describe how we can do this under the hood?
One target audience for this is people with mobility impairment or limited gestures.
(In reply to David Bolter [:davidb] from comment #21) > CC+ Neil Deakin. > > We don't want to instantiate the a11y engine, but we want a way to 'move' > keyboard context (in the keyboard nav sense) to the landmark. I'm not sure > of what we call this. It is like what happens when you 'click' or 'select' > some text and hit tab... I think the tab nav picks up from that point. In > this case we want to move that point to the landmark. I'm not sure what you're referring to, but it sounds like you just want to move the caret.
(In reply to Neil Deakin from comment #23) > (In reply to David Bolter [:davidb] from comment #21) > > CC+ Neil Deakin. > > > > We don't want to instantiate the a11y engine, but we want a way to 'move' > > keyboard context (in the keyboard nav sense) to the landmark. I'm not sure > > of what we call this. It is like what happens when you 'click' or 'select' > > some text and hit tab... I think the tab nav picks up from that point. In > > this case we want to move that point to the landmark. > > > I'm not sure what you're referring to, but it sounds like you just want to > move the caret. I don't really understand the browser internals here, but from the perspective of end users, both screen reader users and other non-mousing populations, it would be very desirable if choosing a landmark region from the tree of landmarks would focus on the element with the landmark role in the same way that it would as if the page author would have put tabindex on that element. As a blind user, I am not completely familiar with visual focus indicator behavior in Firefox, but it is my understanding that putting tabindex>=0 on an element, e.g., a div, will cause a focus rectangle to be drawn around the div. Is that right? When a sighted user chooses to navigate to a landmark region from the tree of landmarks, I think it would be extremely useful for the user to see the region depicted on the screen with a focus rectangle. Would this be possible even if the region does not have a tabindex and is not in the tab order? There are some cases where page authors are putting landmark divs in the tab order to offer additional function such as expanding/collapsing. If this is possible, I would expect that: 1. The user could invoke a context menu for the focused region. 2. If the user presses tab, the focus would move to the next focusable element in the DOM, which may or may not be in the focused region. Maybe it is a bit radical to ask that keyboard focus be given to an element that is not necessarily focusable. But, it solves some other problems, including how to tell any assistive technologies what has happened -- generate focus change event. This is sort of like giving all keyboard users the capability that only screen reader users have today with their virtual cursor functions. Another huge benefit to manipulating the actual keyboard focus is that it aids interaction between blind and sighted users. Right now it takes special tools for sighted users to see region boundaries. It might also be really cool if sighted users could dynamically see the region boundaries as they navigate through the tree of regions. Then pressing enter would close the dialog and align the keyboard focus with the visual indicator.
(In reply to Neil Deakin from comment #23) > (In reply to David Bolter [:davidb] from comment #21) > > CC+ Neil Deakin. > > > > We don't want to instantiate the a11y engine, but we want a way to 'move' > > keyboard context (in the keyboard nav sense) to the landmark. I'm not sure > > of what we call this. It is like what happens when you 'click' or 'select' > > some text and hit tab... I think the tab nav picks up from that point. In > > this case we want to move that point to the landmark. > > > I'm not sure what you're referring to, but it sounds like you just want to > move the caret. Yes! Caret! Thanks :)
there is a addon for firefox hat has been around for a year https://github.com/davidtodd/landmarks
Will Firefox support keyboard navigation using <main> element? In HTML 5.1 spec [1], there is a note which reads: "User agents that support keyboard navigation of content are strongly encouraged to provide a method to navigate to the main element and once navigated to, ensure the next element in the focus order is the first focusable element within the main element. This will provide a simple method for keyboard users to bypass blocks of content such as navigation links. " The keyboard navigation using <main> element allows sighted keyboard users to more easily navigate through web pages. For example, users press "M" key to move the focus to the <main> element, and then press "Tab" key to move the focus to the first focusable element within the <main> element. They won't need to press "Tab" key over again and again any more. W3C User Agent Accessibility Guidelines (UAAG) 1.0 [2] recommends user agents to support the keyboard navigation. "9.9 Allow structured navigation (P2) - Allow the user to navigate efficiently to and among important structural elements in rendered content. - As part of satisfying provision one of this checkpoint, allow forward and backward sequential navigation." The working draft of UAAG 2.0 [3] also encourages user agents to do this at Level A. "2.3.1 Direct Navigation to Important Elements (former 2.7.4): The user can navigate directly to any important (e.g. structural or operable) element in rendered content. (Level A)" It could also make it easier for web developers to provide the mechanism to bypass blocks of content that are repeated on multiple web pages. It is required in WCAG 2.0 at Level A. I'm looking forward to Firefox's support for the keyboard navigation. [1] http://www.w3.org/html/wg/drafts/html/master/grouping-content.html#the-main-element [2] http://www.w3.org/TR/UAAG10/guidelines.html#tech-nav-structure [3] http://www.w3.org/TR/2012/WD-UAAG20-20121004/#sc-231 [4] http://www.w3.org/TR/2008/REC-WCAG20-20081211/#navigation-mechanisms-skip
In addition to what Makoto Ueki wrote in comment #27 I could like to have a visual indicator that can tell a user if the main element is used on a page. Using that it should be possible for a user to discover if they can use the keyboard shortcut for the main element or not.
I agree with Matt in comment 24 who said that sighted users could benefit from this feature too. We are building a web app that has several large named sections, and I have often thought how nice it would be to be able to jump from one section to another without moving my hands from the keyboard. This is what makes using a desktop app so much easier than using a web app - the desktop app has the ability to add "navigation shortcut keys" so that power users can navigate efficiently. Unfortunately, web apps can't easily add shortcut keys because they are already spoken for by the platforms, the browsers, the browser dev tools, and the screen readers and magnifiers that web apps must run in concert with. Because of this, web apps will always feel "more clunky" to me than their equivalent desktop apps. I also agree with Makoto in comment 27 that if there is a <main> element (or an element with role="main") then it should be included in the list of keyboard-navigable landmarks. (To address comment 28, inclusion in the list is what makes it discoverable). I disagree with Jennifer in comment 12 that > Adding the ability to find landmarks in Firefox sounds like a great idea, > but I think it's really best as an extension. There isn't going to be a lot > of demand for outside of users with screenreaders. I think this is actually a pretty important feature to have. As more web applications come online we will need ways to empower users so that they will be more comfortable on the web. Having a navigation mechanism built in to the browser will make it just a little bit easier, because the feature would gradually become familiar to everyone as they adopt it moving forward. The opening comment of this bug says it best, although I would change the last few words as follows: "Expected results: Add a shortcut which opens a window displaying all the landmark regions and makes them accessible for all."
(In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #12) > Adding the ability to find landmarks in Firefox sounds like a great idea, > but I think it's really best as an extension. There isn't going to be a lot > of demand for outside of users with screenreaders. How did you arrive at this conclusion? do you have data to back it up? I would suggest its the exact opposite, screen reader users can already navigate landmarks, support is already built in to most screen readers[1], its users with physical disabilities that make it difficult to use the mouse that will benefit' It is noted that Firefox has lots of built in developer tools[2] that have lots of additional UI (for a relatively small group of users - developers), so it is difficult to understand why a bit of extra UI that would help users with disabilities to navigate and make sense of page content would be rejected. [1] http://blog.paciellogroup.com/2011/07/html5-accessibility-chops-aria-landmark-support/ [2]http://www.howtogeek.com/105320/how-to-use-firefoxs-web-developer-tools/
I'd like to address the focus issues beginning in comment 19: >> Arbitrary elements like landmark containers are not focusable. and continuing in comment 20: > well, not necessarily focusable, ... > its not really clear what it means to navigate to something that isn't focusable. > ... As I understand the bug the main case of interest is the case without a screen reader. Agreed. It's not clear what navigating to a non-focusable element without a screen reader means. So let's work on clarifying. One possibility is to only include landmark elements that are focusable or have focusable children in the list. When the user selects an element from the list, focus can go to its first focusable child element (or if there's any way to know the child element that had focus the last time the landmark was "navigated to", then that might be an interesting possibility). Another possibility is to consider what Matt suggested in comment 24, kind of a pseudo-focus indicator if the landmark element doesn't take focus, and then the next tab key takes you to the first focusable child. This might not be what sighted users want however - I suspect they would prefer to be brought directly to the focusable child. I do, however, love this idea from comment 24: > It might also be really cool if sighted users could dynamically see the region > boundaries as they navigate through the tree of regions. Then pressing enter > would close the dialog and align the keyboard focus with the visual indicator. although, again, I think it might be more efficient to give focus to a focusable child when enter is pressed.
(In reply to Carolyn MacLeod from comment #31) > I'd like to address the focus issues beginning in comment 19: > >> Arbitrary elements like landmark containers are not focusable. > > and continuing in comment 20: > > well, not necessarily focusable, ... > > its not really clear what it means to navigate to something that isn't focusable. > > ... As I understand the bug the main case of interest is the case without a screen reader. > > Agreed. It's not clear what navigating to a non-focusable element without a > screen reader means. So let's work on clarifying. One possibility is to only > include landmark elements that are focusable or have focusable children in > the list. When the user selects an element from the list, focus can go to > its first focusable child element (or if there's any way to know the child > element that had focus the last time the landmark was "navigated to", then > that might be an interesting possibility). > > Another possibility is to consider what Matt suggested in comment 24, kind > of a pseudo-focus indicator if the landmark element doesn't take focus, and > then the next tab key takes you to the first focusable child. This might not > be what sighted users want however - I suspect they would prefer to be > brought directly to the focusable child. I do, however, love this idea from > comment 24: > > It might also be really cool if sighted users could dynamically see the region > > boundaries as they navigate through the tree of regions. Then pressing enter > > would close the dialog and align the keyboard focus with the visual indicator. > although, again, I think it might be more efficient to give focus to a > focusable child when enter is pressed. Hi Carolyn, I suggest you try the firefox landmarks addon https://github.com/davidtodd/landmarks which provides user configurable pseudo focus on selection from a dropdown and also via keystroke. i think it is an important aspect of understanding and discoverability for sighted keyboard users to have a indication of selected region.
(In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #12) > Adding the ability to find landmarks in Firefox sounds like a great idea, > but I think it's really best as an extension. There isn't going to be a lot > of demand for outside of users with screenreaders. > > (In reply to David Bolter [:davidb] from comment #11) > > I also want to understand the intended difference between Quick Find and > > Find bars. This probably belongs on the Find bar, or maybe we want a proper > > nav bar? > > As I understand it, the only difference is that quick find disappears when > you target away from it, and regular find in page stays. If there's actual, > legitimate reason to have both of these, I'll eat my hat and post the video > to YouTube. Hi again, I am still interested in seeing your response to Comment 30 FYI There is now an updated Firefox extension available that provides keyboard navigation for ARIA landmarks and native HTML elements that map onto ARIA landmarks https://github.com/matatk/landmarks/blob/master/README.md I suggest that this functionality would make a useful addition to Native Firefox accessibility UI for users with disabilities. It is noted that Firefox continues to cater for developers needs with additional UI and features(font inspector for example: http://thenextweb.com/dd/2013/03/13/type-lovers-rejoice-mozilla-is-adding-a-font-inspector-to-firefoxs-devtools-available-in-the-latest-nightly/)
"It's not clear what navigating to a non-focusable element without a screen reader means." It means moving the caret, as would happen if a user followed a link to a fragment identifier (e.g. in-page link), no?
had a brief discussion with MarcoZehe on IRC (http://krijnhoetmer.nl/irc-logs/accessibility/20130522#l-118) about relative sizes of developer vs keyboard/alternative input device users the stats here are interesting Dexterity and Mobility Impairment Fact Sheet http://accessibility.gtri.gatech.edu/assistant/acc_info/factsheet_dexterity_mobility.php question of how UI/functionality decisions are made for developer tool additions to Firefox any metrics available?
WEBAIM Survey of Users with Motor Disabilities Results http://webaim.org/projects/motordisabilitysurvey/ "Of note is a very low response to ARIA landmarks, something that would likely provide great benefit to this audience if navigation to them was supported in mainstream browsers." source: http://webaim.org/projects/motordisabilitysurvey/#techniques
Flags: needinfo?(jboriss)
(In reply to steve faulkner from comment #33) > (In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #12) > > Adding the ability to find landmarks in Firefox sounds like a great idea, > > but I think it's really best as an extension. There isn't going to be a lot > > of demand for outside of users with screenreaders. > > > > (In reply to David Bolter [:davidb] from comment #11) > > > I also want to understand the intended difference between Quick Find and > > > Find bars. This probably belongs on the Find bar, or maybe we want a proper > > > nav bar? > > > > As I understand it, the only difference is that quick find disappears when > > you target away from it, and regular find in page stays. If there's actual, > > legitimate reason to have both of these, I'll eat my hat and post the video > > to YouTube. > > Hi again, I am still interested in seeing your response to Comment 30 > > FYI > There is now an updated Firefox extension available that provides keyboard > navigation for ARIA landmarks and native HTML elements that map onto ARIA > landmarks > https://github.com/matatk/landmarks/blob/master/README.md Great. Is this on AMO? (addons.mozilla.org)
(In reply to David Bolter [:davidb] from comment #37) > (In reply to steve faulkner from comment #33) > > (In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #12) > > > Adding the ability to find landmarks in Firefox sounds like a great idea, > > > but I think it's really best as an extension. There isn't going to be a lot > > > of demand for outside of users with screenreaders. > > > > > > (In reply to David Bolter [:davidb] from comment #11) > > > > I also want to understand the intended difference between Quick Find and > > > > Find bars. This probably belongs on the Find bar, or maybe we want a proper > > > > nav bar? > > > > > > As I understand it, the only difference is that quick find disappears when > > > you target away from it, and regular find in page stays. If there's actual, > > > legitimate reason to have both of these, I'll eat my hat and post the video > > > to YouTube. > > > > Hi again, I am still interested in seeing your response to Comment 30 > > > > FYI > > There is now an updated Firefox extension available that provides keyboard > > navigation for ARIA landmarks and native HTML elements that map onto ARIA > > landmarks > > https://github.com/matatk/landmarks/blob/master/README.md > > Great. Is this on AMO? (addons.mozilla.org) Unclear what the push back here is? by providing a simple addition to the firefox UI for keyboard users we can drastically reduce the number of repetitive movements (pushing tab key) required to navigate page content. I would appreciate some feedback on why this is not something that firefox should take a punt with, as there is ample precedence for new UI features being added to Firefox with less robust use cases.
(In reply to steve faulkner from comment #38) > Unclear what the push back here is? by providing a simple addition to the > firefox UI for keyboard users we can drastically reduce the number of > repetitive movements (pushing tab key) required to navigate page content. I > would appreciate some feedback on why this is not something that firefox > should take a punt with, as there is ample precedence for new UI features > being added to Firefox with less robust use cases. Agree. The plugin is nice, but we really need this delivered as part of browser function in order to make the huge advantages of WAI-ARIA regions available to everyone. If integrated with browser, I think it would be advantageous to consider using F6 and shift+F6 instead of letters. F6 is already performing a similar function and it would be logical to extend the F6 focus circle. This may also make the behavior more discoverable. Perhaps Alt+f6 could open the dialog with the treeview of regions that would also be available from the view menu. In addition to being more consistent with similar browser function, Using the function key would eliminate the conflicts that arise when focus is in an input field where the letter keys perform functions such as typing input or navigating lists. You wouldn't want to have to move focus out of an input before being able to move focus to the next region. BTW, the plugin does not use a tree; it indents. a tree that supports expand/collapse and letter key nav would be far superior. Also, I think all users could benefit from pseudo focus drawn around the entire region when navigating to the region. First, this would be a great way to scroll a region into focus. This would also be really useful for screen reader users who often have difficulty scrolling the browser window to accommodate sightees looking on. Second, other useful context function, such as copy, could be provided even on regions with no focusable elements. Finally, this would be a phenominal simplification of landmark test procedures. My final comment is on nested regions. It would be really useful to be able to navigate to only the level 1 (outer most) regions. Perhaps adding ctrl to the key command could perform this function, e.g., ctrl+F6 moves to next level 1 region and shift+ctrl+F6 moves to prior level 1 region. Moving backward should move to the beginning (entirity) of the current region if the focus is contained inside the region. This would give a quick way of returning to the beginning of a region (think of prior track in your music player).
(In reply to steve faulkner from comment #30) > (In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #12) > > Adding the ability to find landmarks in Firefox sounds like a great idea, > > but I think it's really best as an extension. There isn't going to be a lot > > of demand for outside of users with screenreaders. > > How did you arrive at this conclusion? do you have data to back it up? I > would suggest its the exact opposite, screen reader users can already > navigate landmarks, support is already built in to most screen readers[1], > its users with physical disabilities that make it difficult to use the mouse > that will benefit' > > It is noted that Firefox has lots of built in developer tools[2] that have > lots of additional UI (for a relatively small group of users - developers), > so it is difficult to understand why a bit of extra UI that would help users > with disabilities to navigate and make sense of page content would be > rejected. > > > [1] > http://blog.paciellogroup.com/2011/07/html5-accessibility-chops-aria- > landmark-support/ > [2]http://www.howtogeek.com/105320/how-to-use-firefoxs-web-developer-tools/ I'd like to add a voice of support for this functionality. We are putting significant effort into enriching the default Drupal markup in the soon-to-be-released 8 version with ARIA landmarks and meaningful labels. Landmarks navigation benefits blind users, mobility-impaired users and keyboard power-users. We're taking an approach of building the front-end UI from ARIA out in what we're calling the semantic application layer. I would love to see more access to this layer of the DOM through APIs and keyboard-optimized interaction. The adoption of Drupal 8 in 2014 and the following years will lead to a wealth of sites on the internet that are highly qualified with ARIA attribution. We're getting the content ready for you :)
I have put together a Concept for integrating keyboard navigation of HTML5 structural elements/ ARIA landmarks into Firefox https://docs.google.com/document/d/11yzSsHorM3mkG8fLk_etdY-jcpYjZIHAKT3qDzkuyMI/edit?usp=sharing
(In reply to steve faulkner from comment #41) > I have put together a Concept for integrating keyboard navigation of HTML5 > structural elements/ ARIA landmarks into Firefox > https://docs.google.com/document/d/11yzSsHorM3mkG8fLk_etdY- > jcpYjZIHAKT3qDzkuyMI/edit?usp=sharing nice, for the method #1 probably it makes sense to use side bar instead however addressbar navigation looks fascinating Also I like hotkey method #2, probably it makes sense to keep both
(In reply to alexander :surkov from comment #42) > (In reply to steve faulkner from comment #41) > > I have put together a Concept for integrating keyboard navigation of HTML5 > > structural elements/ ARIA landmarks into Firefox > > https://docs.google.com/document/d/11yzSsHorM3mkG8fLk_etdY- > > jcpYjZIHAKT3qDzkuyMI/edit?usp=sharing > > nice, for the method #1 probably it makes sense to use side bar instead > however addressbar navigation looks fascinating > > Also I like hotkey method #2, probably it makes sense to keep both It is intended that both methods be implemented, address bar is suggested to provide alternative navigation without having to add UI. the address bar method is to allow initial quick nav to any part of the page.
cc'ing Gijs since he wears an a11y hat on front-end and can make sure this is the priority work backlog as appropriate.
Flags: needinfo?(jboriss)
(In reply to David Bolter [:davidb] from comment #44) > cc'ing Gijs since he wears an a11y hat on front-end and can make sure this > is the priority work backlog as appropriate. This seems to be assigned to Eitan? Confused about whether work is ongoing or not (don't have time to read the entire bug right now; will self-needinfo). What do other browsers do here?
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(dbolter)
(In reply to :Gijs Kruitbosch from comment #45) > What do other browsers do here? Nothing. No browser currently does anything beyond, at best, exposing info via the accessibility API and leaving it up to additional assistive technology to do something sensible with it. So, for instance, running JAWS on top of Firefox will give the user access to further keyboard shortcuts (through JAWS) to navigate to landmarks. This is fine for keyboard users that also run AT, but misses out keyboard-only users that do not. (Opera used to provide keyboard shortcuts for jumping to different headings etc, but that's all been removed as far as I know)
(In reply to :Gijs Kruitbosch from comment #45) > (In reply to David Bolter [:davidb] from comment #44) > > cc'ing Gijs since he wears an a11y hat on front-end and can make sure this > > is the priority work backlog as appropriate. > > This seems to be assigned to Eitan? Confused about whether work is ongoing > or not (don't have time to read the entire bug right now; will > self-needinfo). > > What do other browsers do here? if you wanna talk about it ping me on #accessibility IRC
So, having read the bug and played around with the add-on for a bit, this still pretty desperately needs (a) a compelling UI proposal and (b) a compelling usecase that (a) would serve well. For (a), or why the current add-on-proposed UI isn't good enough: 1) We can't really add single-key navigation keys by default. To my knowledge, besides the arrow key, spacebar, escape and enter, none of the alphanumeric keys are taken by the browser - by any browser, in fact. So just making 'n' and 'p' (or any other letter/shift-letter combo) do magical things is unlikely to be good for web compat. For a high profile example, try using https://www.google.co.uk/?gfe_rd=cr#q=foo - Google automatically appends any alphanumeric input to the search box, even if it wasn't focused. We'd want landmark navigation to work there, too, but clearly breaking websites who handle keybindings is a tricky and controversial subject ( bug 380637, bug 1053430, bug 1052569, https://code.google.com/p/chromium/issues/detail?id=33056 ). Taking single-key shortcuts by default would be wrong; not always taking them will make this unpredictable and therefore much less useful. 2) The submenu solution really doesn't scale, and is unusable on high profile websites. On http://www.bbc.co.uk/news/ I just get "navigation", "-search" (what's with all the initial dashes - is this meant to make it look like a tree?) and "contentinfo", none of which have meaning for the user. On http://www.nytimes.com/ the situation is significantly worse, with some 30-odd "-contentinfo" items in the menu. The documentation says we use aria-label and aria-labelledby (I guess otherwise we're using the node name?) - we should use the first bit of text or something similar, at a minimum, and that probably requires more space than just a submenu (nevermind wanting to actually have a proper tree). As for the usecase, even as a heavily-keyboard-oriented user, I'm not sure I see the value proposition here. For sighted/non-screenreader users (as screenreader users get this functionality from their screenreader, AIUI), what do landmarks do that find in page and skip-link/space/tab doesn't already do (and faster/better) ? If the landmarks aren't adequately labelled (which seems like it is the case, from my limited testing), the functionality is essentially useless for finding something you're looking for (because which of the umptillion "contentinfo" things is what you want?) - find in page is much more efficient. For browsing, the examples I tried either didn't use them as much more than skip links (bbc) or had so many of them that it was essentially no more efficient than a skip link + tab (ny times). It almost seems to me that if we were going to do something like this, offering navigation by headers would be more sensible as a first step. If you are still convinced that this should be implemented in the core product, I think the first step would be sitting down (and I mean actually sitting down/vidyo/skype/whatever, not bug comments and needinfo) with one of the UX designers and explaining: - what these roles are; - for what usecases they're useful to the general public and/or why implementing this in an add-on for the specific user groups that want it isn't good enough; - what information we have and don't have about the landmarks, generally speaking (e.g., most seem to be unlabelled right now, though I readily admit that my study is wholly unscientific) and to ask them to figure out how to incorporate functionality here. I'd nominate :phlsa as the first person to talk to. I'm happy to facilitate a meeting if that helps, but I'm not the right person to do the UX stuff here myself. Leaving dbolter's needinfo to see how to best move this further.
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to :Gijs Kruitbosch from comment #48) > As for the usecase, even as a heavily-keyboard-oriented user, I'm not sure I > see the value proposition here. For sighted/non-screenreader users (as > screenreader users get this functionality from their screenreader, AIUI), > what do landmarks do that find in page and skip-link/space/tab doesn't > already do (and faster/better) ? The fact that a solution built directly into the browser, taking advantage of explicit semantics defined in the document, is arguably better than one that relies on devs having to manually add skip links into their documents? One that works even when developers did NOT add skip links?
I think others answered the question asked of me. Maybe we should just implement skip to main content first. Not sure what the key-combo would be... note I think FF for android probably has good heuristics we could co-opt.
Flags: needinfo?(dbolter)
(In reply to David Bolter [:davidb] from comment #50) > I think others answered the question asked of me. Maybe we should just > implement skip to main content first. Not sure what the key-combo would > be... note I think FF for android probably has good heuristics we could > co-opt. the other feature I find quite useful is to have shortcut get into search section concerning to shortcuts we could use doubled combos like CMD+G(go to)+S(search) or CMD+G+M(main) not sure if doubled combos are a11y problem by itself since are timing dependent.
> > As for the usecase, even as a heavily-keyboard-oriented user, I'm not sure I > > see the value proposition here. For sighted/non-screenreader users (as > > screenreader users get this functionality from their screenreader, AIUI), > > what do landmarks do that find in page and skip-link/space/tab doesn't > > already do (and faster/better) ? If this is done well, the value proposition is enormous for both users and page authors. But, that is a big IF. BTW, I do not think the current plugins do a good job of modeling an ideal solution. Skip links require finding and focusing on the skip link. What if you had to put focus on a certain link to move to the browser menubar? Right, silly. Skip links are silly, buggy, a web 1.0 1990's hack. Now, we have to think like the web is the desktop. Very nice aspects of pressing and releasing alt in Windows applications to focus in the menubar is that 1) it works from any spot in the app where it makes sense and 2) it is always the same key. Find is only good if you know what you are looking for. It is not a general navigation and exploration method. It is a lousy approach for people who must use the keyboard but have major dexterity challenges. For those people, we need a very small set of single key presses (not the entire alphabet), e.g., tab, space, arrows, enter, F6, F10, etc. With a very small handful of keys, one should be able to get anywhere on a page with a very small number of key presses. This would be good for ALL users. > The fact that a solution built directly into the browser, taking advantage > of explicit semantics defined in the document, is arguably better than one > that relies on devs having to manually add skip links into their documents? > One that works even when developers did NOT add skip links? Precisely, if page authors say "here is the IA of my page" using WAI-ARIA regions, then the browser could make that IA easily navigable without the author providing any silly skip links, extra JS that will vary from site to site in its UI, or access keys that are impossible to remember. And, while we do have a bit of a chicken and egg problem as only a small portion of page authors understand WAI-ARIA regions, there are nonetheless millions of pages that do have really good use of WAI-ARIA regions. The IBM internet and intranet sites have millions anyway. And, they are starting to show up across the web. If Firefox provided really excellent support, then page authors would see the advantage. BTW, I do mean literally "see". I 100% agree with Gijs's comment that UE work is needed; it is needed badly, and I would personally love to help with the interaction model piece. I think we need to think from the ground up about the problem being solved. I have some simple ideas that may be a bit radical but could increase the value of semantic structural markup with WAI-ARIA regions by 1000 fold and simplify the web for all. Browsers that do this right will have an indisputable a11y advantage. Where/how is the best way to discuss this? At some point some real conversation is needed. Should I add more to this bug? BTW, these bugzilla pages are perfect example of pages that desparately need both a good IA and navigation solution. As a JAWS user, the experience is a giant time suck. But, if this is the people's choice for the place to discuss further, I will do whatever it takes to contribute to a high-value and game-changing solution to this problem.
If ARIA was exposed to all users, it would be better implemented. Simply making it easily available will make it a higher priority for people to implement.
Related issue on Headings here https://bugzilla.mozilla.org/show_bug.cgi?id=1140572
I would like to add my name to the list of people who would like to have this feature implemented natively in the browser. Marco Zehe and I went back and forth a bit by email recently, and he seemed skeptical that this should be a native feature of the browser, but I'm strongly in favor of it. In fact, I'd like to be able to navigate by keyboard through headings as well as landmarks. We can save quite a few keystrokes that way, which is an enormous benefit to people using switch access devices, or who otherwise can't use a mouse. Ideally there would be some fast and easy keystroke, like the add-on that uses Control + N or P. Let users decide which modifier key(s) to use. You could also steal a concept from VoiceOver and have a key combination bring up a rotor, which users could then toggle through. If you did that, you could let users navigate to headings, landmarks, images, forms, frames, and a number of other things. Let's finally get rid of "Skip navigation" links by implementing this! The lack of keyboard features for sighted keyboard users is the only reason we still have to put those links in. I'd like to see them die, and be replaced by native browser support for that simple functionality.
(In reply to :Gijs Kruitbosch (away until Aug 3) from comment #48) > So, having read the bug and played around with the add-on for a bit, this > still pretty desperately needs (a) a compelling UI proposal and (b) a > compelling usecase that (a) would serve well. The compelling usecase is that navigation of web content for keyboard users sucks. > > For (a), or why the current add-on-proposed UI isn't good enough: because navigation of web content for keyboard only users should be a built in UA feature. > > 1) We can't really add single-key navigation keys by default. To my > knowledge, besides the arrow key, spacebar, escape and enter, none of the > alphanumeric keys are taken by the browser - by any browser, in fact. So > just making 'n' and 'p' (or any other letter/shift-letter combo) do magical > things is unlikely to be good for web compat. For a high profile example, > try using https://www.google.co.uk/?gfe_rd=cr#q=foo - Google automatically > appends any alphanumeric input to the search box, even if it wasn't focused. > We'd want landmark navigation to work there, too, but clearly breaking > websites who handle keybindings is a tricky and controversial subject ( bug > 380637, bug 1053430, bug 1052569, > https://code.google.com/p/chromium/issues/detail?id=33056 ). Taking > single-key shortcuts by default would be wrong; not always taking them will > make this unpredictable and therefore much less useful. so key combinations would be OK? > > 2) The submenu solution really doesn't scale, and is unusable on high > profile websites. On http://www.bbc.co.uk/news/ I just get "navigation", > "-search" (what's with all the initial dashes - is this meant to make it > look like a tree?) and "contentinfo", none of which have meaning for the > user. On http://www.nytimes.com/ the situation is significantly worse, with > some 30-odd "-contentinfo" items in the menu. The documentation says we use > aria-label and aria-labelledby (I guess otherwise we're using the node > name?) - we should use the first bit of text or something similar, at a > minimum, and that probably requires more space than just a submenu > (nevermind wanting to actually have a proper tree) This is an example only, it is not meant to be the blessed functionality. > > As for the usecase, even as a heavily-keyboard-oriented user, I'm not sure I > see the value proposition here. For sighted/non-screenreader users (as > screenreader users get this functionality from their screenreader, AIUI), > what do landmarks do that find in page and skip-link/space/tab doesn't > already do (and faster/better) ? >find in page does not modify focus order As far as I can tell. The usability win for keyboard users is that navigation via landmarks moves focus so that next stab stop becomes the first focusable element in the landmark navigated to. Example improvement: https://gear.mozilla.org/collections/apparel to get to the serach box via tab = 10 key strokes via landmark = 5 key strokes = 50% less key strokes to get to the first item of apparel (in main content) via tab = 12 keystrokes via landmark = 5 keystrokes = 60% less key strokes to get to the first link on the footer via tab = 37 keystrokes via landmark = 5 = 32 less keystrokes. > > If the landmarks aren't adequately labelled (which seems like it is the > case, from my limited testing), the functionality is essentially useless for > finding something you're looking for (because which of the umptillion > "contentinfo" things is what you want?) - find in page is much more > efficient. there should only be 1 or 2 footers/content infos that are navigable in each page not umptillion. > > For browsing, the examples I tried either didn't use them as much more than > skip links (bbc) or had so many of them that it was essentially no more > efficient than a skip link + tab (ny times). what needs to happen is data review on usage and fashioning of navigation rules based on what and how they are used in real world > > It almost seems to me that if we were going to do something like this, > offering navigation by headers would be more sensible as a first step. I think that offering hotkeys for <header> role = banner <main> role=main <footer> role=contentinfo and <hx> would be a good initial implementation > > If you are still convinced that this should be implemented in the core > product, I think the first step would be sitting down (and I mean actually > sitting down/vidyo/skype/whatever, not bug comments and needinfo) with one > of the UX designers and explaining: > - what these roles are; > - for what usecases they're useful to the general public and/or why > implementing this in an add-on for the specific user groups that want it > isn't good enough; > - what information we have and don't have about the landmarks, generally > speaking (e.g., most seem to be unlabelled right now, though I readily admit > that my study is wholly unscientific) > > and to ask them to figure out how to incorporate functionality here. I'd > nominate :phlsa as the first person to talk to. I'm happy to facilitate a > meeting if that helps, but I'm not the right person to do the UX stuff here > myself. Leaving dbolter's needinfo to see how to best move this further. OK please do set up a meet.
(In reply to steve faulkner from comment #56) > (In reply to :Gijs Kruitbosch (away until Aug 3) from comment #48) > > So, having read the bug and played around with the add-on for a bit, this > > still pretty desperately needs (a) a compelling UI proposal and (b) a > > compelling usecase that (a) would serve well. > > The compelling usecase is that navigation of web content for keyboard users > sucks. > > > > > For (a), or why the current add-on-proposed UI isn't good enough: > > because navigation of web content for keyboard only users should be a built > in UA feature. Sure, but my point was that we need a viable UI/UX proposal and this wasn't one. > so key combinations would be OK? Some key combinations (but not all because accesskeys) would be less likely to conflict, yes. Unfortunately, the available keyspace, to borrow a crypto term, is very small. Finding a shortcut that both makes sense and is available x-platform will be hard. > > As for the usecase, even as a heavily-keyboard-oriented user, I'm not sure I > > see the value proposition here. For sighted/non-screenreader users (as > > screenreader users get this functionality from their screenreader, AIUI), > > what do landmarks do that find in page and skip-link/space/tab doesn't > > already do (and faster/better) ? > > >find in page > does not modify focus order As far as I can tell. Find in page (links only) does modify focus. You can activate it with the ' key. For page headers, normal find should work (as you can't and don't need to focus the actual header). I think it would be helpful if we changed find in page (links only) to be extended to label text for form controls if it doesn't already (but that is a separate bug). That might actually be more useful for keyboard navigation than trying to iterate over landmarks with previous/next. > there should only be 1 or 2 footers/content infos that are navigable in each > page not umptillion. And images on the web should have proper alt texts. The difference between what we are saying is "should" and "are". > > For browsing, the examples I tried either didn't use them as much more than > > skip links (bbc) or had so many of them that it was essentially no more > > efficient than a skip link + tab (ny times). > > what needs to happen is data review on usage and fashioning of navigation > rules based on what and how they are used in real world Have any other browser or AT vendors, or a11y specialists done such data review? Certainly the front-end folks who have been pinged about this, myself and :phlsa included, likely do not have the time to do such a review. > > It almost seems to me that if we were going to do something like this, > > offering navigation by headers would be more sensible as a first step. > > I think that offering hotkeys for > <header> role = banner > <main> role=main > <footer> role=contentinfo > and <hx> > > would be a good initial implementation This would not actually benefit the mozilla gear store example in the way you proposed apart from role=main, right? You might still be right (that this would be a good start), but I'm concerned that this is strawman #2 which seems to fall apart quite quickly. Real data as you suggested above would be very helpful. I'd also be interested in hearing what is/isn't wrong with the find in page (links only) that I mentioned. > > If you are still convinced that this should be implemented in the core > > product, I think the first step would be sitting down (and I mean actually > > sitting down/vidyo/skype/whatever, not bug comments and needinfo) with one > > of the UX designers and explaining: > > > - what these roles are; > > - for what usecases they're useful to the general public and/or why > > implementing this in an add-on for the specific user groups that want it > > isn't good enough; > > - what information we have and don't have about the landmarks, generally > > speaking (e.g., most seem to be unlabelled right now, though I readily admit > > that my study is wholly unscientific) > > > > and to ask them to figure out how to incorporate functionality here. I'd > > nominate :phlsa as the first person to talk to. I'm happy to facilitate a > > meeting if that helps, but I'm not the right person to do the UX stuff here > > myself. Leaving dbolter's needinfo to see how to best move this further. > > OK please do set up a meet. -> davidb to assess how to proceed here.
Flags: needinfo?(dbolter)
I think Steve is going to bring a simplified proposal.
Flags: needinfo?(dbolter)
Here is an alternate proposal for the UI. Most of this has been touched on already (by Marco, Matt, and others), but I'd like to flesh it out a bit more. This proposal has 2 parts: 1) Quick traversal of "top-level" sections/landmarks/panes with F6 and Shift+F6. 2) Open Outline sidebar with Ctrl+F6 on Win or Command-Shift-F6 on Mac (*very* similar to History sidebar that opens with Ctrl+H on Windows or Command-Shift-H on Mac). Before I describe these 2 parts in more depth, I want to establish 2 things: A) Why F6? - Firefox currently defines F6 and Shift+F6 as traversing frames [1] but <frame> is now obsolete [2], so I think we can repurpose (i.e. mostly augment) F6 and Shift+F6 now. - F6 and Shift+F6 have been used to traverse "panes" for a very long time (including Windows Explorer in Windows XP [3], or Word in Windows 95 [4], as well as browsers on multiple platforms [5]), so the idea of using F6 to traverse larger chunks of content is "written in the ancient runes". This makes it very discoverable by keyboard users. B) This feature is about both HTML5 sectioning content [6] and WAI-ARIA landmark roles [7]. - Although it is implied in the title of this bug, and "section elements" have been mentioned, I just want to make it explicitly clear that we are talking about HTML5 sectioning content (including h1-h6 when they implicitly define sections) as well as ARIA landmark roles; in short, anything that the page author expects to contribute to an "outline". - Unfortunately, the HTML5 outline algorithm [8] is incomplete, because it does not take ARIA roles into account. For example, a <div> with role="region" and a label would be expected to be part of an outline, but the algorithm wouldn't find it. However, the algorithm is probably a good place to start, as long as ARIA roles are considered along with sectioning content. - In that light, default ARIA roles [9] must also be taken into account. For example, a <header> that is not a descendant of an article or section has a default role of "banner", and a <footer> that is not a descendant of an article or section has a default role of "contentinfo", which classifies these elements as landmarks. Also, <main> is not sectioning content, but because it has a default role of main, it is a landmark. - In order to simplify this discussion, and keep both HTML5 and ARIA in mind, I am going to call any element that goes in the outline a "section/landmark" element. - For reference: - sectioning content [6]: article, aside, nav, section - landmark roles [7]: application, banner, complementary, contentinfo, form, main, navigation, region, search - heading content that may define an implied section [10]: h1, h2, h3, h4, h5, h6 Now for the details (with apologies to @SteveFaulkner, but I agree with others that single-letter keys don't allow traversal through editable elements, and a menu/#nav doesn't scale for presenting all section/landmark elements neatly. Steve, I am very interested in your feedback on this proposal). 1) Quick traversal - details - F6 traverses (scrolls and gives focus) to the next "top level" section/landmark - Shift+F6 traverses to the previous "top level" section/landmark - "top level" means only section/landmark elements that are not descendants of sectioning content elements (i.e. their ancestor sectioning root is <body>) - consider expanding the definition of "top level" to include direct section/landmark descendants of <main> as well - the 2014 WebAIM Screen Reader User Survey [11] noted that somewhere around 6 or so landmarks were reported as being optimal. Of course, some documents are large, with many top-level sections, like a book with chapters. I think that for such documents, users would still find F6 useful to jump to the next or previous "chapter", even though they would not likely use it to go through all chapters. - only section/landmarks with at least one focusable child will be traversed - consider allowing section/landmarks with no focusable children to participate by moving the caret to the first caret-browseable child (this would have to be thoroughly tested to see if it makes sense to "navigate" between focusable elements and non-focusable caret-browseable elements; i.e. should you change the user's caret browsing (F7) mode, or just move the caret? It may even make sense to select the non-focusable element or the first word of the non-focusable element so that the user believes that the element has been "navigated" to). - if the section/landmark has more than one focusable child, focus goes to the first focusable child - consider navigating to the "current" focusable child (i.e. the aria-activedescendant) instead of the first - F6 and Shift+F6 still continue to traverse to the address bar and history sidebar (and the new outline sidebar described below) - F6 and Shift+F6 will no longer traverse <frame> elements (this could be phased out, if necessary, and eliminated when frame use drops below a certain level) 2) Outline sidebar - details - Ctrl+F6 (Win) or Command-Shift-F6 (Mac) opens an Outline sidebar which looks/feels almost identical to the History sidebar, including search field and filter combo on top, and tree below (please type Ctrl+H (Win) or Command-Shift-H (Mac) in a Firefox browser so that you can follow along as I describe details) - Differences are: - the tree contains all of the section/landmark elements discovered by our "role-augmented" outline algorithm (mentioned in B, above) - the name/label of each section/landmark element (used for the tree item's label) comes from the accessible name [12] of the heading for the section element (for example, <h1>name</h1> or aria-labelledby="nameID" or aria-label="name"), or the accessible name of the landmark element. - in the complete absence of a name, consider using the role or tag as the name, i.e. "main", "footer", "banner", "search" - typing a name/label in the search field of the new Outline sidebar filters the tree to show only section/landmarks with the typed text in their name/label - selecting a section/landmark type in the filter combo filters the tree to show only section/landmarks of that type (default is "all"; and "sectioning content" and "landmarks" could be in the combo as well) - consider allowing multi-select on the filter combo, so that users can choose to show, for example, section+main+region+article, or form+search+nav+navigation - tree items can have icons based on type (go wild <g>), or simply based on whether the element is "sectioning content" or a "landmark" (or both) - selecting a tree item, by either single-clicking it with the mouse or using arrow keys in the tree, scrolls the page so that the selected section/landmark is in view - consider drawing a [temporary] border around the section/landmark to show exactly where it is - activating a tree item, by either double-clicking it with the mouse or using arrow keys in the tree followed by enter; scrolls, optionally draws a temporary border, and then gives focus to the first focusable child of the section/element (if it has a focusable child; if not, then focus just stays in the tree) - consider navigating to the "current" focusable child (i.e. the aria-activedescendant) instead of the first - consider moving the caret, as with Quick traversal, if there are no focusable children - F6 and Shift+F6 traverse out of the Outline sidebar in a similar manner to the way F6/Shift+F6 currently traverse out of the History sidebar. Points to consider: - Perhaps this bug should be filed under "General"? Or maybe "Keyboard Navigation"? - Should sectioning content elements with role="presentation" be included in the outline? Probably not? - Should sectioning content elements with non-landmark roles, such as a <section role="marquee"> or <section role="dialog"> or <aside role="note"> be included? Probably? - Mac OS X apparently has Control-F6 and Shift-Control-F6 to Move the focus to the next/previous panel [13], however I don't think (?) this will be a problem, because Firefox on Mac OS X is already using F6 and Shift-F6, and our Outline sidebar would use Command-Shift-F6. - I chose Ctrl+F6 (Win) and Command-Shift-F6 (Mac) for the Outline sidebar shortcut to align with the History sidebar shortcut of Ctrl+H (Win) and Command-Shift-H (Mac). If preferred, consider using combinations of Alt with F6 (FYI, apparently some apps use, or used to use, Ctrl+F6 and/or Alt+F6 to cycle through their open windows). - For mobile devices, Outline could be provided at the top of the Awesome Screen with History, Top Sites, and Bookmarks [14], with tap and hold for more options. [15] A couple of final thoughts: As Matt and others have said, this could be a very powerful feature - differentiating even - if it is done right. Those who use a keyboard or alternative input device would benefit immediately, and keyboard power-users would enjoy traversing larger areas of content without reaching for the mouse. It is the kind of feature that could become indispensable to many users. While this feature may not immediately impact screen reader users (because screen readers already have this capability), I believe that by making semantic structure visible to sighted developers and designers, screen reader users would benefit in the long run because web pages would be more likely to be created with semantic structure in mind. [1] https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly [2] http://www.w3.org/TR/html5-diff/#obsolete-elements [3] https://support.microsoft.com/en-us/kb/126449 [4] https://support.microsoft.com/en-us/kb/135000 [5] https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts [6] http://www.w3.org/html/wg/drafts/html/master/dom.html#sectioning-content [7] http://www.w3.org/TR/wai-aria-1.1/#landmark [8] http://www.w3.org/html/wg/drafts/html/master/semantics.html#outline [9] http://www.w3.org/TR/html-aria/#docconformance [10] http://www.w3.org/html/wg/drafts/html/master/semantics.html#headings-and-sections [11] http://webaim.org/projects/screenreadersurvey5/#numlandmarks [12] http://www.w3.org/TR/accname-aam-1.1/#mapping_additional_nd_te [13] https://support.apple.com/en-ca/HT204434 [14] https://support.mozilla.org/en-US/kb/use-awesome-screen-search-web-bookmarks-and-more [15] https://support.mozilla.org/en-US/kb/use-gestures-in-firefox-android
Attached image ff-outline-view.png —
Perhaps the proposal in comment 59 can be simplified: a) Just implement the Outline sidebar (part 2) for now. (We can decide later if we still want to have Quick traversal (part 1)). b) Ignore the broken HTML5 outline algorithm (I had naively hoped it would get fixed). If we treat headings and section/landmarks separately, we don't need it. c) Never mind the "filter combo" - it just complicates things. d) Ignore 'application' because it is no longer a landmark role in ARIA 1.1. [1] e) Only list regions (including <section> elements with default role="region") if they have a label (specified by aria-label, aria-labelledby, title, or first heading child). f) We probably should only list HTML5 sectioning content elements whose implicit or explicit role is a landmark role. That would mean <article> is not in the list by default because its implicit role is 'article', which is not a landmark role. It also rules out things like <section role="marquee"> and <section role="dialog"> and any sectioning element with role="presentation". We can revisit this point in more detail later, if, for example, user feedback indicates that they expect articles to be listed. I've attached a mockup of one possible implementation of this simplified Outline sidebar. It's just like the Ctrl+H History sidebar, except it's called "Outline", the View menu contains "Landmarks" and "Headings" radio items, and the tree contains a hierarchical list of either the section/landmarks or the headings on the current web page. The mockup shows section/landmarks on a fictional web site after the user typed Ctrl+F6 to open the Outline sidebar (which placed focus in the search field), then tab twice to move to the tree, and then down arrow until the Main landmark was selected (alternatively, they could have typed Main in the search field). At this point, we need to decide what will happen if the user activates the Main tree item (by typing Enter or Space, or double-clicking). My personal preference is for the web page to scroll if necessary to ensure that Main is in view, and then give focus to the first (or current) focusable child in the Main element. If there is no focusable child, then set the caret (aka selection [2]) at the beginning of the Main element. It might even make sense to also scroll the web page as the user selects the tree items (with arrow keys or single-click of mouse). Note that since the section/landmark names in the Outline are user-facing (and not just for developers), I chose which names to display. For example, I chose Banner instead of header because header is too easy to mix up with heading. I chose Navigation instead of nav because it's a full word. I went with Complimentary and Region instead of aside and section because they were the landmark names, but those could go either way. And I chose Footer instead of contentinfo, because, well, what's a contentinfo? :) If the section/landmark has a label (required for role="region" in order to be included in the Outline tree, but optional on other section/landmarks) then I displayed the section/landmark name, followed by colon, followed by the label. Alternatively, the label could go first; so in the mockup, "Navigation: Site" would be listed as "Site Navigation", "Region: Messages" would be "Messages Region", and "Complimentary: Carousel" would be "Carousel Complimentary" or perhaps "Carousel Aside". Please work with me to get this thing specified, so that someone can implement it. With the 508 Refresh due this fall, having heading and section/landmark navigation implemented natively in the browser would go a long way towards encouraging web designers and developers to semantically organize their pages. [1] https://rawgit.com/w3c/aria/master/aria/aria.html#landmark_roles [2] https://www.w3.org/TR/UAAG20-Reference/#def-selection
Slack has implemented landmark navigation using F6 (SHIFT+F6) in their desktop (Electron) app; or CTRL+F6 (CTRL+SHIFT+F6) in browsers. It's quite nice. Please give it a try to get an idea of what landmark navigation could feel like if implemented natively in browsers. https://get.slack.help/hc/en-us/articles/115003340723-Keyboard-accessibility-in-Slack-
Flags: needinfo?(mzehe)
I am aware of F6, however I am not the deciding factor here. If you read through the history on this bug, there seem to still be a lot of unanswered questions.
Flags: needinfo?(mzehe)
> I am not the deciding factor here. Bugzilla tells me that you are the triage owner. Is this bug filed under the wrong component? > If you read through the history on this bug, there seem to still be a lot of unanswered questions. Some of the questions have been answered through new insights over time. Other questions are design decisions and opportunities for the team. Which questions do you feel are blocking this?
Flags: needinfo?(mzehe)
(In reply to Carolyn MacLeod from comment #66) > > I am not the deciding factor here. > > Bugzilla tells me that you are the triage owner. Is this bug filed under the > wrong component? Ultimately, since this is front-end, yes. The unanswered questions are, for one thing, which keyboard shortcuts to use, and other things surrounding the expected UX. F6, to stick with your example, already is being used in Firefox to switch between several major browser components, so cannot be used to also switch between landmarks on a page, or this will become very confusing. So implementing this requires a defined UX, which is one part this has so far been blocked on, and an implementation following that by the front-end team. So while this is the correct entry point for this kind of bug, ultimately others will implement it, namely either someone from the Firefox front-end team, or someone submitting a patch as a volunteer, which is always possible.
Flags: needinfo?(mzehe)
> which keyboard shortcuts to use ... F6 already is being used in Firefox to switch between several major browser components, so cannot be used to also switch between landmarks on a page, or this will become very confusing. F6 (and Shift+F6) might be confusing, or they might be seen as a nice way to teleport around the browser. I think F6 merits user testing, or at least discussion. However, that said, Slack's decision to use Ctrl+F6 (and Ctrl+Shift+F6) within the browsers works very well. > this is front-end How can we get the attention of the front-end team?
Flags: needinfo?(mzehe)
They do have their attention on this bug. But as I wrote to you in the web-a11y Slack, this is about more than just throwing keyboard focus somewhere, because those elements aren't focusable by spec by default currently, and in order for a proper implementation that does not mess too much with website's JS logic, would require adjustments on the spec level first. That's why we advocate for using/creating add-ons for this kind of task currently, since if they mess with the website, it's a more controlled environment and the source can be spotted more easily if there are problems.
Flags: needinfo?(mzehe)

The following will work (and if preferred, can be implemented just for HTML elements that have an implicit landmark role [1]):

  • User types next-landmark shortcut key
  • Browser scrolls to start of next landmark (similar to scrolling to a fragment [2])
  • Browser moves Sequential Focus Navigation Starting Point (SFNSP) [2] to start of next landmark
  • Browser moves focus to body if landmark is not focusable (same as for in-page links with non-focusable target element)
  • User can type tab (or shift+tab) to move focus to next (previous) focusable element after (before) SFNSP

Similar behavior for previous-landmark.
If there's no next (previous) landmark then wrap to first (last) landmark.

Just need to decide what shortcut key(s) to use.
Ctrl+F6 and Shift+Ctrl+F6 (Cmd+F6 and Shift+Cmd+F6 on Mac) may be the best choice, but that's up to you to decide. Would be nice if it was the same in all browsers.
Matt Atkinson's excellent Landmarks extension uses Alt+Shift+N and Alt+Shift+P which works nicely in most places, but not in text fields on a Mac (Alt inserts special characters).

[1] HTML elements that have an implicit landmark role:

  • HTML header (in body scope), footer (in body scope), main, nav, aside
  • HTML form and section if aria-label[ledby] [3]
  • The only ARIA landmark not covered by the above HTML elements is search (input type=search defaults to searchbox role, not search). Willing to live with that 1 omission.

[2] Sequential Focus Navigation Starting Point (SFNSP):

[3] From the User Agent Support section of the ARIA spec:

The WAI-ARIA specification neither requires nor forbids user agents from enhancing native presentation and interaction behaviors on the basis of WAI-ARIA markup. Mainstream user agents might expose WAI-ARIA navigational landmarks (for example, as a dialog box or through a keyboard command) with the intention to facilitate navigation for all users. User agents are encouraged to maximize their usefulness to users, including users without disabilities.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: