Handling Presentational role conflict resolution #1189
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Jym77
changed the title
WilcoFiers
previously requested changes
Mar 25, 2020
Co-Authored-By: Wilco Fiers <WilcoFiers@users.noreply.github.com>
Co-Authored-By: Wilco Fiers <WilcoFiers@users.noreply.github.com>
jeeyyy
approved these changes
Apr 2, 2020
WilcoFiers
previously requested changes
Apr 6, 2020
pages/glossary/hidden.md
Outdated
| @@ -0,0 +1,19 @@ | |||
| --- | |||
| title: Explicitly Hidden | |||
There was a problem hiding this comment.
Thinking about this a little more... I don't think I like having a "hidden" definition that isn't the opposite of the "visible" definition. We did that in axe-core and it's pretty confusing. I think we should rename this to "hidden state", and say it can be either true or false.
There was a problem hiding this comment.
Which is why I called it "explicitly hidden" in the first place #1189 (comment) 😆
"hidden state" is also a good name.
|
Final Call ends on April 28th. |
Jym77
added
Review call 2 weeks
carlosapaduarte
added a commit
that referenced
this pull request
Apr 23, 2020
…pose (fd3a94) (#693) * Create links-with-identical-names-and-context-serve-equivalent-purpose-fd3a94.md * Create programatically-determined-link-context.md * Inserting links to definitions in Assumptions * Insert reference to WCAG definition * Change link text for WCAG definition link * Fixed spelling * Fixed spelling * Delete programatically-determined-link-context.md There is already a working definition * Update links-with-identical-names-and-context-serve-equivalent-purpose-fd3a94.md * Update links-with-identical-names-and-context-serve-equivalent-purpose-fd3a94.md * Update _rules/links-with-identical-names-and-context-serve-equivalent-purpose-fd3a94.md Co-Authored-By: Jean-Yves Moyen <jym@siteimprove.com> * Update _rules/links-with-identical-names-and-context-serve-equivalent-purpose-fd3a94.md Co-Authored-By: Jean-Yves Moyen <jym@siteimprove.com> * Update _rules/links-with-identical-names-and-context-serve-equivalent-purpose-fd3a94.md Co-Authored-By: Jean-Yves Moyen <jym@siteimprove.com> * Update links-with-identical-names-and-context-serve-equivalent-purpose-fd3a94.md * Removed inapplicable example 4 Following #1189 * Update _rules/links-with-identical-names-and-context-serve-equivalent-purpose-fd3a94.md Co-Authored-By: Wilco Fiers <WilcoFiers@users.noreply.github.com> * Update links-with-identical-names-and-context-serve-equivalent-purpose-fd3a94.md * Update links-with-identical-names-and-context-serve-equivalent-purpose-fd3a94.md * fix: ignore attr lowercase html validation * Update links-with-identical-names-and-context-serve-equivalent-purpose-fd3a94.md * Update _rules/links-with-identical-names-and-context-serve-equivalent-purpose-fd3a94.md Co-Authored-By: Wilco Fiers <WilcoFiers@users.noreply.github.com> * Update links-with-identical-names-and-context-serve-equivalent-purpose-fd3a94.md * Update links-with-identical-names-and-context-serve-equivalent-purpose-fd3a94.md * Update links-with-identical-names-and-context-serve-equivalent-purpose-fd3a94.md * Apply suggestions from code review Co-Authored-By: daniel-montalvo <49305434+daniel-montalvo@users.noreply.github.com> * Update links-with-identical-names-and-context-serve-equivalent-purpose-fd3a94.md * Update links-with-identical-names-and-context-serve-equivalent-purpose-fd3a94.md * Update links-with-identical-names-and-context-serve-equivalent-purpose-fd3a94.md Co-authored-by: jkodu <jey.nandakumar@gmail.com> Co-authored-by: carlosapaduarte <carlosapaduarte@gmail.com> Co-authored-by: Jean-Yves Moyen <jym@siteimprove.com> Co-authored-by: Wilco Fiers <WilcoFiers@users.noreply.github.com> Co-authored-by: daniel-montalvo <49305434+daniel-montalvo@users.noreply.github.com>
|
Final Call has ended. Merging. |
8 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Presentational roles conflict resolution states that elements with a
role="none"must be exposed with their implicit role if they have either a globalaria-*attribute (e.g.aria-label) or are focusable. This was completely ignored by our definition of semantic role.This resolution is not well implemented in all browsers (https://github.com/act-rules/act-rules.github.io/wiki/Tests-on-Presentational-role-Conflict-resolution). A side note being the handling of
aria-hiddenon focusable elements for which there is no specs and browsers are doing different things.This PR updates the definition of semantic role to take the resolution into account. The role is linked to the actual role in the accessibility tree to circumvent both the discrepancies between browsers (we do with what we have instead of taking side) and the ambiguous "interactive" term in the spec (we don't decide what is interactive, we just do with whatever the UA is giving us). The new examples are however following the specs (which is also what Chrome, the majority browser, does).
I have also removed examples with
aria-hiddenon focusable elements. Because there is no spec for what do to in that case, and browsers disagree, I preferred taking these examples out because what to do is far from clear.I considered that "ARIA state or property is permitted" was the main rule to test the definition and added several examples there. Other rules are mostly using the role incidentally and only got one extra example (usually a Failed one as "when do we fail?" is the important question for our rules).
The definition of "marked as decorative" also ended up as collateral damage of this PR. There was somewhat of an internal contradiction between "having a role of
none" and achieving that by "explicitly settingrole="none"" (which does not work because of the conflict resolution). Where it was important, "marked as decorative" as been replaced by "role ofnone" which seems to work.We might still need a definition of "marked as decorative" which would be in the line of "explicit role of
none" so that something could be marked as decorative (expressing intention of the writer) without actually having a role ofnone(due to conflict resolution) and that would likely indicate some sort of failure or at least bad practice (i.e. explicitly settingrole="none" aria-label="foo"is a bad idea as there is conflict between the intention of hiding stuff and showing it).Changes ripples all over the place and in many rules. Please take a close look and also try to figure out if I've missed something… Keep the problem in mind when looking at other rules in the near future.
Closes issue(s):
Need for Final Call:
This will require a 2 weeks Final Call (changes many rules, has lot of implications).
Pull Request Etiquette
When creating PR:
developbranch (left side).After creating PR:
Rule,DefinitionorChore.How to Review And Approve