Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Move delay option to before feed content to support keyboard users #877

Open
aardrian opened this issue Sep 7, 2018 · 5 comments
Open

Move delay option to before feed content to support keyboard users #877

aardrian opened this issue Sep 7, 2018 · 5 comments

Comments

@aardrian
Copy link
Contributor

@aardrian aardrian commented Sep 7, 2018

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).

@gaurav5430

This comment has been minimized.

Copy link

@gaurav5430 gaurav5430 commented Feb 5, 2019

Can i take this up?
it seems an easier solution is to just place the <select> element before the feed in the DOM.

@mcking65

This comment has been minimized.

Copy link
Contributor

@mcking65 mcking65 commented Feb 5, 2019

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.

@mcking65

This comment has been minimized.

Copy link
Contributor

@mcking65 mcking65 commented Feb 5, 2019

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.

@aardrian

This comment has been minimized.

Copy link
Contributor Author

@aardrian aardrian commented Feb 5, 2019

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?

@aardrian

This comment has been minimized.

Copy link
Contributor Author

@aardrian aardrian commented Jul 3, 2019

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.

aardrian added a commit to aardrian/aria-practices that referenced this issue Oct 3, 2019
Addresses w3c#877.
aardrian added a commit to aardrian/aria-practices that referenced this issue Oct 3, 2019
Addresses w3c#877.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.