New rule: First focusable element is link to non-repeated content

[Jym77]

Extracting the separate rule from #421 .

Closes issue(s):

• N/A

Need for Final Call:
This will require a 2 weeks Final Call (new rule)

---

Pull Request Etiquette

When creating PR:

• Make sure you're requesting to pull a branch (right side) to the develop branch (left side).
• Make sure you do not remove the "How to Review and Approve" section in your pull request description

After creating PR:

• Add yourself (and co-authors) as "Assignees" for PR.
• Add label to indicate if it's a Rule, Definition or Chore.
• Link the PR to any issue it solves. This will be done automatically by referencing the issue at the top of this comment in the indicated place.
• Optionally request feedback from anyone in particular by assigning them as "Reviewers".

When merging a PR:

• Close any issue that the PR resolves. This will happen automatically upon merging if the PR was correctly linked to the issue, e.g. by referencing the issue at the top of this comment.

How to Review And Approve

• Go to the “Files changed” tab
• Here you will have the option to leave comments on different lines.
• Once the review is completed, find the “Review changes” button in the top right, select “Approve” (if you are really confident in the rule) or "Request changes" and click “Submit review”.
• Make sure to also review the proposed Final Call period. In case of disagreement, the longer period wins.

[Jym77]

Copying from https://github.com/act-rules/act-rules.github.io/pull/421/files#r562630136

Under what circumstance would this not be true? This one is a little tricky. What do you mean with "by use of the keyboard"? If I have an on-screen cursor that I control using arrow keys, and use space to fire a click event from the cursor, does that count? Arguably it would, but I suspect that's not what you mean. Additionally, are you expecting the click event to be fired when the element is focused? Could event bubbling be involved?

[Jym77]

I don't think that a mouse-emulator should count. It's a separate assistive technology and I don't think that it should be taken into account.

If such an emulator would count, then we could argue that every thing satisfies 2.1.1 as soon as users have such an emulator. This is quite clearly not the intend of 2.1.1…

I think rules only test what is part of the test subject (usually a web page).

Now, if a web page implements a mouse emulation with keyboard, that is another question. I would say that such a page does satisfy 2.1.1 (maybe not in a very good way, however). In Scrollable element is keyboard accessible, we do have an assumption (maybe a bit weak) around this idea. (I would argue that currently a page with a mouse emulation implemented could fail the rule but satisfy 2.1.1 and it's not completely clear that this is caught by the assumption).

Anyway, here, if a page implements a mouse emulation, then yes, you can fire the click event by use of keyboard only. But that is not always the case.

Foo">

Foo

Is passing the first two conditions (it is part of sequential focus navigation, and visible when focused), but not the 3rd (that may be browser dependant, but on Chrome I do not manage to fire the click event with space or enter even when the element has focus). So I do not think that this condition is always true.

[carlosapaduarte]

I think we can take another approach.
To meet the expectation of the rule, the element needs to be activated (so that a change of focus can be evaluated). So, for this rule, we don't need to check if it is possible to activate (fire a click event at) an element twice.
I suggest we drop this definition and move being part of the sequential focus navigation and being visible when focused to the expectations of the rule. The third condition in this definition is already checked in the rule's expectation.

[Jym77]

The important point in this third condition is not that the element can be activated, but the fact that it can be done by using the keyboard. This is what fails Failed Example 7, and is not checked elsewhere in the rule.

Without this condition,

Skip to main content

">

<div role="link" onclick="location.assign('#main');" tabindex="0" id="skip-link">Skip to main contentdiv>

[carlosapaduarte]

You are correct. I was focusing too much on the "how can we know if we can fire an event at a target" and leaving out the "using the keyboard" parte.

Still, what about changing the condition in the expectation to

- when the element is [activated][] by use of keyboard, focus moves [just before][] a node of [non-repeated content after repeated content][]; and

[Jym77]

🤔 Interesting…

I'm afraid that this condition is dangerously close to triggering a universal quantification on an empty set… The almost similar

If the element is activated by use of keyboard, focus moves…

for example, would pass on elements that are not keyboard-actionable (or we can make this even more explicit with "every time the element is activated by use of keyboard, …")

Now, clearly, the current formulation also has that problem… It can be rephrased the same way as

Every time the element is activated, …

and would pass on a non-activatable element (whatever that means…) But the current version does have a condition that the element is actionable (as part of the keyboard actionable requirement…)

---

Also, to continue discussion… If I open the devtools (Ctrl+Shift+I, usually), go to the console, and type in some document.getElement(foo).sendEvent(click), is that keyboard activation? I guess we're safe-ish because that uses something (devtools) which is not part of the content (the web page), so if that gives extra power, we don't care (the same way that we wouldn't take into account a browser extension that allows to move the pointer with the k.eyboard).

[shunguoy]

I am not sure if this can be programmatically checked. I would like this to be a manual rule.

[WilcoFiers]

Referencing back to our conversation of mechanism, I don't think these two are required. Actually if a skip mechanism was a button, I'm not entirely sure it'd even fail WCAG.

[Jym77]

I'm convinced that a skip button wouldn't fail WCAG (and would pass Document has an instrument to move focus to non-repeated content), but this is best practice matching G1 which does require a link as skip mechanism.

The technique does not explicitly mention keyboard activation nor inclusion in the accessibility tree, but does mention "keyboard only users" and "screen reader users" for which the link would be useless without these conditions. I'm rather keen to keep them in a best practice rule (especially since this does not refer to "instrument", contrary to the other cases discussed, and so we cannot rely on that definition to tell that "instrument" must be accessible).

[WilcoFiers]

Shouldn't this be part of the applicability? I don't quite see the logic of failing a page without focusable content.

[WilcoFiers]

This too seems a bit out of scope for the technique.

[Jym77]

That's essentially the 2nd test in the technique ("Check that the description of the link communicates that it links to the main content.")

[Jym77]

@WilcoFiers good catch on the presence of repeated content. That was lost in various iterations…
This lead me to make a composite rule with one atomic checking for repeated content and another for skip link.

Rule updated.