Make use of the error quick navigation command in browse mode on the web

[LeonarddeR]

Originally suggested by @jcsteh in #6942 (comment)

we could extend this to cover form fields with aria-invalid, which might
be useful when trying to find out which field you messed up when filling
out a compliant form.

Using the w and shift+w quicknav commands in browse mode on the web now reports "not supported in this document". Based on @jcsteh's suggestion, I'd like to suggest this command to allow navigation to the following:

• Form fields with aria-invalid (i.e. with controlTypes.STATE_INVALID_ENTRY in the list of states for the element, if I'm correct)
• Elements with the aria-required attribute in the following situations:
  • Single and multi line edit boxes with an empty value
  • Unchecked check boxes
  • Unpressed toggle buttons
  • Combo boxes without a selection
  • ...

The first one is probably quite easy to implement. I see more problems with the aria-required cases. I think we should consider these cases as invalid, but there are probably edge cases I haven't thought of yet.

[LeonarddeR]

Some research revealed something I did not yet know, we have the aria-required attribute, but of course there is the HTMl5 required attribute as well, which automatically sets the invalid state in Firefox, Chrome and Edge. People should use required instead of aria-required, so I don't think we need to add support for required explicitly, invalid entry should be enough. It seems IE 11 doesn't expose the html5 required attribute though.

[derekriemer]

If we do reqquired, something like a quiz where each radio button is required, but only one in the group must be eleected.

…

On Sat, Jun 24, 2017 at 3:17 AM, Leonard de Ruijter < ***@***.***> wrote: Some research revealed something I did not yet know, we have the aria-required attribute, but of course there is the HTMl5 required attribute as well, which automatically sets the invalid state in Firefox, Chrome and Edge. People should use required instead of aria-required, so I don't think we need to add support for required explicitly, invalid entry should be enough. It seems IE 11 doesn't expose the html5 required attribute though. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#7320 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFGivbRlzyVOJt791QGYu9Levg6YfsE-ks5sHNQMgaJpZM4OEQpA> .

-- Derek Riemer: Improving the world one byte at a time! - University of Colorado Boulder Department of computer science, 4th year undergraduate student. - Accessibility enthusiast. - Proud user of the NVDA screen reader. - Open source enthusiast. - Skier. Personal website <http://derekriemer.com>

[LeonarddeR]

I've made a first attempt to implement the command for invalid_entry, and I noticed that
<div aria-invalid="true">content</div> is also navigated. I wonder whether we should explicitly block these situations with a check for the focusable state.

[jcsteh]

Is there a good use case for an author to do something like that? If so, do we see that use case as something which should be easily navigable? Or if we do restrict to focusable, are we just protecting users from author error? In this case, it's a trivial change, so I don't mind even if we choose to do that, but we should be clear about the use cases.

One use case I can think of is using aria-invalid in a document to indicate sections which need revision; e.g. a teacher marking an assignment. However, that might be far fetched.

[LeonarddeR]

One use case I can think of is using aria-invalid in a document to indicate sections which need revision; e.g. a teacher marking an assignment.

I agree. Note that aria-invalid also supports the spelling and grammar values. So I assume an author writing

<p>You made a <strong aria-invalid='spelling'>missssssstake</strong></p>

is perfectly valid here. We don't report the invalid state for text nodes in browse mode though, so that might be confusing somehow. We should at least report spelling errors in text that are marked as such, but that is for a separate issue.

[LeonarddeR]

@jcsteh @michaelDCurran, would be nice to have your opinion about which path to follow here. I'm leaning towards the approach where we use w and shift+w navigation to jump to web objects with the invalid state in Firefox, Chrome and Edge. I'm getting more and more reluctant about the idea to add a custom guessing mechanism to IE, so I think it should either not be implemented there, or be only supported for explicit aria-invalid cases.

[michaelDCurran]

I think supporting aria-invalid="true" in IE is fine, but I don't believe guessing would be a good choice.

[bhavyashah]

@LeonarddeR Do you think we could incorporate #5630's variation of the use of 'w' on the web under the umbrella of this ticket?

[lukaszgo1]

What about navigating to the actual spelling errors? For example ad least in Firefox when you wrote misspelled word in some edit field the fact that it is an spelling error is reported even in browse mode. Would it be possible to navigate to it with W? Should create a separate ticket for it?

[Adriani90]

@LeonarddeR what about adding form fields with aria-invalid/"true" to elements list instead? Then w and shift+w could be used for spelling errors only which would be consistent with aother applications. A gesture for aria-invalid="true" could be assigned in the input gestures dialog, in case users need it.