SC2-1-2-no-keyboard-trap-standard-navigation (Updated) about act-rules.github.io HOT 24 CLOSED

I suggest defining "focus into", or rephrasing it. What I'm guessing you mean is that it contains an element that's in the focus order?

About "focus out of". I think this can be misunderstood. If I open a lightbox, and that disabled all focusable elements in the background, and there is no way with keyboard to dismiss it, is this an element I can't "focus out of"?

It seems to me that the point of this SC is to make sure that, regardless of what state a page is in, you should never be prevented from accessing the browser UI.

from act-rules.github.io.

See also related discussion on R2.

The SC says "focus can be moved to" and "focus can be moved away from". Following that, here is a suggested rewrite:

Applicability: All components on a web page where focus can be moved to through keyboard navigation.
Expectation: Focus can be moved away from the component by using arrow keys, ESC key, TAB key, Shift+TAB or Enter key.

from act-rules.github.io.

@nitedog Again, still not keen on the term "component". HTML doesn't have the concept of components, so you'll have to define it, otherwise it doesn't meet the requirement of being objective.

from act-rules.github.io.

WCAG 2.1 provides a refined definition for "User Interface Components", which seems to include the term "Components" (see Note 3). It seems that "Component" is a short-hand for "User Interface Component". Does that help?

from act-rules.github.io.

It helps in that "is perceived by the user as" clearly isn't objective. :)

from act-rules.github.io.

Is there a term you already use in other rules? This issue seems broader than this rule alone. I don't think we should define a counter term to what WCAG already uses. Instead, it may be better to seek clarification for this existing term (eg. in the Understanding documentation).

from act-rules.github.io.

Most WCAG 2.0 definitions can't be used in rules. This is by design. WCAG 2.0 definitions are open-ended, so that they can be applied to future technologies. Where as definitions in rules should never be open-ended, because that's what causes all those interpretation problems in success criteria.

If you recall, one of the biggest concerns with moving to the applicability/expectation approach, was that it would be too open-ended. We don't want to just take the SC text and pour it into the rules format template. That doesn't get rid of any interpretation differences. To push rule writers to being more precise about this we've put in the latest ACT Rules format draft that applicability must be objective.

Ask yourself: What about this definition can I express objectively? The advantage of this is that you're not technology agnostic. Most of the rules do things like give a list of node names, or roles, or certain attributes to look for. Essentially you create a whitelist of everything you know to fit within that definition. That's not easy, and sometimes that's a little painful too because you'll have to ignore things you know to be issues, because you can't define them well enough.

from act-rules.github.io.

So again I ask, is there already a term being used in other rules? It seems that this term -- whatever it is called and however it is defined -- will be needed in several rules. Is there a common glossary of terms for ACT Rules?

from act-rules.github.io.

This is the only thing that comes close:
https://github.com/auto-wcag/auto-wcag/blob/master/pages/algorithms/interactive-element.md

I don't think that would work for this rule though, since you're not trying to prevent focus from being trapped on a single element, but within a group of elements.

from act-rules.github.io.

I think it applies to single and group of objects/elements/components.

Actually, what is the definition of element, is it the the HTML definition?

from act-rules.github.io.

Yeah, HTML / ARIA / DOM / CSS terms would work.

from act-rules.github.io.

I updated the proposal at top of this thread using the term "element" instead of "component".

from act-rules.github.io.

We have updated the format based on the format here : #66

from act-rules.github.io.

I can understand the reasoning behind using the term "element". I still think that "component" could be more suited, because it also includes focusable content that is not written in HTML.

from act-rules.github.io.

Ok, so this rule would fail things like the following:

<button onblur="setTimeout(() => this.focus(), 10)">Evil</button>

But it doesn't actually fail the following:

<button onblur="setTimeout(() => this.nextSibling.focus(), 10)">Evil1 </button>
<button onblur="setTimeout(() => this.previousSibling.focus(), 10)">Evil2 </button>

Any thoughts on how we could do that?

from act-rules.github.io.

We have updated the Expectation part in the proposal to try to cover the situation commented by Wilco. Any thoughts?

from act-rules.github.io.

Wilco's comment: I don't think the logic of this works. Firstly because the "next element on the page" can be any element, I was going to suggest the "next element in the focus order", but I don't think that's true either. In things like ARIA tabs the next tab shouldn't be in the focus order. You should make sure this rule doesn't become a test that checks that the focus order makes sense. That's entirely different SC, and not the problem you are trying to describe.

This one is difficult to review without knowing what is going to be in the R2 rule.

from act-rules.github.io.

This code seems relevant: https://github.com/jquery/jquery-ui/blob/master/ui/focusable.js

from act-rules.github.io.

Perhaps the expectation shouldn't define what focus is moving to, only that it can be moved away from where is currently is. Something like...

For each target HTML element, or subsection of HTML elements, focus can be moved away from that element/s by using one or more of the following:

from act-rules.github.io.

Dagfinn, Geir Sindre, Stein Erik and Anne changed the whole Applicability + Expectations.

Please provide feedback on this new approach (see first comment in thread).

Old Test Procedure that we have replaced:

Applicability

The rule applies to any HTML elements and subsections of HTML elements on a web page where focus can be moved to through keyboard navigation.

Expectation

For each target HTML element, or subsection of HTML elements, focus can be moved away to an HTML element that has not previously had focus, by using one or more of the following:

• Tab key
• Shift+Tab
• Arrow keys
• Esc key
• Enter key

from act-rules.github.io.

Checked in with Kasper Isager, and we suggest editing the Applicability a bit:

"The rule applies to any HTML or SVG element on a web page that is [focusable][] by keyboard." -->
"The rule applies to any HTML or SVG element on a web page that is [focusable][] and reachable through [sequential focus navigation] (https://www.w3.org/TR/html/editing.html#sequential-focus-navigation)."

"by keyboard" is suggested removed because we found this normative definition of "focusable" that says that focusable means that the element "can become the target of keyboard input".

There's also this spec for what it means that something can be focused: https://www.w3.org/TR/html/editing.html#can-be-focused

from act-rules.github.io.

@geirsf, Did you see the suggestion above about editing the Applicability?

I'm also wondering if we should add more test cases. Don't know how many we need, but I've started thinking of some:

Passed

<div tabindex=“1”>Text</div>

<!-- something with tabindex=0 ? -->

Inapplicable

<a href="#" tabindex="-1">Tab key cannot reach here!</a>

<button type="button" disabled>Click Me!</button>

<button type="button" style=“display: none;”>Click Me!</button>

<!-- something with tabindex=0 ? -->

from act-rules.github.io.

Added the new applicability from Anna to this and #68 and added your testcases.

from act-rules.github.io.

Made into pull request: #142

from act-rules.github.io.