aria-practices
aria-practices copied to clipboard
w3c
Move delay option to before feed content to support keyboard users
Affected Page This is for he example feed pattern at https://www.w3.org/TR/wai-aria-practices-1.1/examples/feed/feedDisplay.html
Issue
The example has a feature to adjust the delay time for loading new items. The <select> menu for this feature does not appear in the code until after the feed content.
For a keyboard-only user, there is no way to get to the <select> menu without first tabbing through the feed. The feed continues to add new items, meaning the keyboard-only user cannot get out of the feed to get to the <select> menu.
A screen reader user can jump to just form controls, but each example in the feed has a form control (the <button>s) so the same problem occurs. A screen reader user cannot Shift + Tab backwards past the start of the document to get to the <select> menu (which appears last in the page). A more skilled screen reader user might jump to the final item on the page (using Ctrl + End for example in NVDA), but the user still needs to know that something is there.
Steps to Reproduce Either one of these will demonstrate the issue:
- Open the linked example and, without using the mouse, use just the keyboard to get to the
<select>menu. - Open the linked example in your preferred screen reader and, without using the mouse, navigate to the
<select>menu.
Suggested Resolution
Make the<select> menu the first item on the page (in the DOM at least).
Can i take this up?
it seems an easier solution is to just place the <select> element before the feed in the DOM.
As noted on the documentation page, this example is an early draft that still needs work.
The design of the display page is not complete. It needs content both before and after the feed to illustrate how to nest feeds in a page.
There is a keyboard feature for moving past the feed. On this example, it is ctrl+end. See the example documentation page. One problem, of course, is that there is nothing present in the experience that helps the user know that.
Before we decide whether to move the delay selector, I think we should first discuss what else to include in the design of the feed display page to make it somewhat realistic as well as how to reveal the existing keyboard affordences. Once we decide what else to add to the page, we can decide where the delay selector best fits.
One thing we definitely want to include is the standard set of navigation links for example pages as well as a link to the example documentation page.
BTW, one of the issues the feed pattern is intended to resolve is getting keyboard focus out of infinitely scrolling content in situations where the content cannot be contained in a single composite widget that manages focus.
As noted on the documentation page, this example is an early draft that still needs work.
Agreed. However, I am aware of a reference internal to an organization that links to the example, not the documentation. With no warnings on the example, nor link to the documentation, these users are unaware of the "needs work" or "draft" status of the example.
There is a keyboard feature for moving past the feed. On this example, it is ctrl+end. See the example documentation page. One problem, of course, is that there is nothing present in the experience that helps the user know that.
And with people linking directly to the example, they will not discover that.
So if understanding these points is predicated on the documentation page, then how about linking the documentation page as the first tab-stop on the example page?
Can you do that more easily than moving the <select> to before the feed in the DOM?
This has sat for 5 months. I have had to tell a client yet again today that, no, the pattern is just coded weirdly, but the concepts are still valid.
@gaurav5430 , if you are not allowed to move the <select> then I will do a PR.
Sorry if I still do not understand why it would be better to place the delay menu at the top of the example. Doing so doesn't support the intention of the design of this page.
To illustrate the features of the feed pattern, we need at least one focusable element after the feed. That is necessary to demonstrate and test the ability to jump past feed.
The delay menu is an experimental control for simulating a slow connection that may impact how the feed interoperates with assistive technologies. It is of little or no use to the typical reader of this page. So, that is why we chose the delay menu to be a post-feed element.
If we are going to add content to the page prior to the feed, wouldn't it be better to add something that is more relevant to the typical user? Earlier, it was suggested that a link back to the documentation page would be a quick fix that would add some value.
It'd be wonderful if we could prioritize making this example more helpful. Given all the combobox and carousel work along with the new guidance sections, I unfortunately don't see how we could get it done for the March release, but we could for July.
One thing we clearly need is to add something to the design that reveals the key commands. From the top comment in this issue, it seems like the lack of that is the primary driver of this issue. Is that correct?
Sorry if I still do not understand why it would be better to place the delay menu at the top of the example. Doing so doesn't support the intention of the design of this page.
The intention is unknown to people accessing this page directly (see above where I note an org pointing to the page, not the explainer). Putting a control after the feed that itself modifies the feed looks and feels like a bug to everyone I have seen use this.
To illustrate the features of the feed pattern, we need at least one focusable element after the feed. That is necessary to demonstrate and test the ability to jump past feed.
So put a fake footer? Or an anchor link to the top of the page?
The delay menu is an experimental control for simulating a slow connection that may impact how the feed interoperates with assistive technologies. It is of little or no use to the typical reader of this page. So, that is why we chose the delay menu to be a post-feed element.
Who do you think is the typical reader of this page?
If we are going to add content to the page prior to the feed, wouldn't it be better to add something that is more relevant to the typical user? Earlier, it was suggested that a link back to the documentation page would be a quick fix that would add some value.
A link will add value and should have been there already (especially since URL hacking from a deep link is not perfect). In the meantime, since I know how long it takes to hammer out language edits, how about we approve the PR today? Given that it looks like a bug otherwise, it seems like low-hanging fruit to approve.
It'd be wonderful if we could prioritize making this example more helpful. Given all the combobox and carousel work along with the new guidance sections, I unfortunately don't see how we could get it done for the March release, but we could for July.
All the more reason to approve the PR today.
One thing we clearly need is to add something to the design that reveals the key commands. From the top comment in this issue, it seems like the lack of that is the primary driver of this issue. Is that correct?
No, the primary driver is the interactive control after the feed, which looks like a bug. If your intent was to show the keyboard commands, then you will need to add that too (above the feed, for SR users). In the meantime, let's approve the PR while the other language gets word-smithed.
For future consideration on example patterns, given how I keep seeing links directly to a pattern page and not the document explaining it, it might be better not to write a pattern without at least an opening statement linking to the documentation.
Can I ask why the feed example is a separate page to begin with? Why isn’t it in the example page like all the others?
Irregardless, I think it’s safe to move the delay menu before the feed. We can add some bogus or other usable focusable after the feed.
Because the original link is 404, this is its new URL with the same issue: https://www.w3.org/WAI/ARIA/apg/example-index/feed/feedDisplay.html