Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
// Expose <kbd> as a group, but only if it has a title.
Is this behavior in a specification? If so, please link to it.
// Do not use tooltip text for the name of an unfocusable node with a
Link to specification requiring this. (is it the one linked on line 4749?)
// happens correctly, the below line CanSetFocusAttribute() catch this case.
```suggestion
// happens correctly, the below line CanSetFocusAttribute() catches this case.
```
// TODO(accessibility) Test to see whether the following content works in
Is there a plan to do that soon? A tracking bug?
// TODO(accessibility) Fix WebUI and remove this.
Is there a plan to do that soon? A tracking bug?
name: "AccessibilityProhibitedNames",
What's the goal of making this experimental instead of test?
FAIL child_4.isIgnored should be false. Was true.
Why is this now failing?
CONSOLE ERROR: An accessible name was placed on a prohibited role. This causes inconsistent behavior in screen readers. For example, <div aria-label="foo"> is invalid as it is not accessible in every screen reader, because they expect only to read the inner contents of certain types of containers. Please add a valid role or put the name on a different object. As a repair technique, the browser will place the prohibited name in the accessible description field. To learn more, see the section 'Roles which cannot be named' in the ARIA specification at https://w3c.github.io/aria/#namefromprohibited.
This is hard to fix?
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
// Expose <kbd> as a group, but only if it has a title.
Is this behavior in a specification? If so, please link to it.
Removing this, because the issue in the interop test was addressed in the linked github issue.
// Do not use tooltip text for the name of an unfocusable node with a
Link to specification requiring this. (is it the one linked on line 4749?)
Done.
// happens correctly, the below line CanSetFocusAttribute() catch this case.
```suggestion
// happens correctly, the below line CanSetFocusAttribute() catches this case.
```
Done
// TODO(accessibility) Test to see whether the following content works in
Is there a plan to do that soon? A tracking bug?
Added TODO(crbug.com/350528330) as this task is listed there.
Is there a plan to do that soon? A tracking bug?
Added TODO(crbug.com/350528330) as this task is listed there.
What's the goal of making this experimental instead of test?
Changed to test.
FAIL child_4.isIgnored should be false. Was true.
Why is this now failing?
Thanks, this should say PASS. It's now ignored because we are more correct, and we ignore the aria-hidden div that is not part of a label.
CONSOLE ERROR: An accessible name was placed on a prohibited role. This causes inconsistent behavior in screen readers. For example, <div aria-label="foo"> is invalid as it is not accessible in every screen reader, because they expect only to read the inner contents of certain types of containers. Please add a valid role or put the name on a different object. As a repair technique, the browser will place the prohibited name in the accessible description field. To learn more, see the section 'Roles which cannot be named' in the ARIA specification at https://w3c.github.io/aria/#namefromprohibited.
This is hard to fix?
It's working as expected. For the element `<div role="definition" aria-label="definition name" data-knownFailure>This is a definition</div>`, we are supposed to output this error to the console. If it was in Web UI we would also trigger a DCHECK.
So even though it says Console error, that's what we want it to say.
Open to suggestions to make this less surprising.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Commit-Queue | +1 |
Looks like I have more Web UI to fix first.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |