-
Notifications
You must be signed in to change notification settings - Fork 70
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
New Rule: Create Semantic Focus (a20046) #559
Conversation
Scemantic Focus
Outdated
|
||
## Applicability | ||
|
||
The rule applies to all element in the sequential focus navigation excepts scrollable content element. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- "all elements" is pretty vague. I propose "all HTML and SVG elements"
- "sequential focus navigation" must be defined
- "scrollable content element" must be defined
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[sequential focus navigation](https://www.w3.org/TR/html/editing.html#sec-sequential-focus-navigation
Scemantic Focus
Outdated
|
||
## Assumptions | ||
|
||
- Giving focus to scrollable content elements is the only way to scroll non interactive content using a keyboard. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think I understand why this is an assumption. Can you clarify?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would have been better to have this as note in the applicability instead of an assumption. But after reviewing the definition of focusable are I don't think this is needed, given that if a scrollable region of an element is focusable, then it should have a semantic role so that users of AT can understand what role that region plays.
Scemantic Focus
Outdated
Element in sequential navigation doesnot have semantic role | ||
|
||
```html | ||
<a href="#desc" tabindex="0" aria-hidden="true">More</a> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This scenario is addressed by a different role: https://act-rules.github.io/rules/6cfa84 I suggest that we avoid overlap by adding "that is included in the accessibility tree" to the applicability.
Scemantic Focus
Outdated
#### Passed Example 4 | ||
|
||
|
||
### Failed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add a test where you override the role of an element that's focusable by default.
Scemantic Focus
Outdated
<div href="#desc" role="presentation" tabindex="0">More</div> | ||
``` | ||
|
||
### Inapplicable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add a test where you disable an element to remove it from focus sequence.
Scemantic Focus
Outdated
This rule checks that every element part of the sequential focus navigation has a semantic role. | ||
|
||
accessibility_requirements: | ||
wcag20:2.4.4: # Link Purpose (In Context) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't believe this is a failure of 2.4.4. More generally, while I'm totally on board with this rule, I don't believe this is a failure of WCAG 2.1 at all. I've had that discussion in the past, this rule looks quite a lot like something we have in axe-core today. Here's a link to that conversation:
dequelabs/axe-core#632
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anne suggested 4.1.2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anne suggested 4.1.2
This would also not fail 4.1.2
4.1.2 asks a role of all "user interface components". But if a piece of text with a span on it suddenly receives focus (because of tabindex for example) that doesn't make that piece of text a user interface component because it doesn't control anything.
I agree that it is a good rule (because most of the time it will point to a 4.1.2 violation) but it is currently not necessarily a WCAG failure to fail this rule.
Siteimprove doesn't think this rule is testing for anything required by WCAG. |
Although I think this is an interesting rule that can definitely indicate accessibility failures, it probably doesn't explicitly test anything in WCAG. @WilcoFiers , I think this also depends on the definition of "user interface components" because if user interface components include things that receive focus, those things will need a role or fail 4.1.2. |
Revised the rule addressing previous comments. As an outcome of the revision, I do believe that now this addressed 4.1.2. More comments welcomed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If everyone else is agreed that this rule would be part of checks for conformance for 4.1.2, which I'm OK with, then I think this is looking good. I've suggested a grammatical change in the description, but the rest seems to be fine.
This rule checks that every element that is part of the sequential focus navigation order has a semantic role. | ||
|
||
accessibility_requirements: | ||
wcag20:4.1.2: # Name, Role, Value (A) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would (still) not say this fails WCAG 4.1.2.
A Div with tabindex is not a user interface component and doesn't need a role.
@ramitgarg any updates on these? |
@JKODU we decided last week to drop this one since it does not address any SC. do you want us to keep working on it? |
This seems to have "Should we proceed" for a while? Have we reached a conclusion on the same? |
As far as I recall, the last time this was discussed in a meeting, the conclusion was to leave it on hold because this is not testing a SC, but it's just a best practice. |
<< Describe the changes >>
Closes issue: (ADD ISSUE NUMBER HERE)
Guidance for the PR (pull request) creator
When creating PR:
After creating PR:
Rule
,Definition
orChore
(more to the administrative side)How to Review And Approve