Skip to content
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

fix: ignore invalid and allow redundant role in aria-allowed-role #1118

Merged
merged 9 commits into from
Sep 7, 2018

Conversation

jeeyyy
Copy link
Contributor

@jeeyyy jeeyyy commented Aug 31, 2018

This PR tackles fix for ignoring invalid roles and allowing redundant roles in aria-allowed role. It also handles backwards compatibility for ARIA 1 vs 1.1 for certain roles like combobox, spinbutton and searchbox.

Closes issue:

Reviewer checks

Required fields, to be filled out by PR reviewer(s)

  • Follows the commit message policy, appropriate for next version
  • Has documentation updated, a DU ticket, or requires no documentation change
  • Includes new tests, or was unnecessary
  • Code is reviewed for security by: @WilcoFiers

@jeeyyy jeeyyy requested a review from a team as a code owner August 31, 2018 05:39
@jeeyyy jeeyyy changed the title [WIP] fix: ignore invalid and allow redundant role in aria-allowed-role fix: ignore invalid and allow redundant role in aria-allowed-role Sep 3, 2018
@jeeyyy
Copy link
Contributor Author

jeeyyy commented Sep 3, 2018

@dylanb - kindly review, believe it will be good to release a patch this week with these fixes.

checks['aria-allowed-role'].evaluate.call(checkContext, node)
);
});

it('returns false when MENU has type context', function() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like the test description needs to be inverted to match the new expected result.


if (segments) {
return validRoles;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not at all obvious that segments wouldn't return the implicit role. I'm also not a fan of having this turn into a thing that can return either strings or arrays. You're trying to do two things with the same function. I suggest you keep the getRoleSegments function around, and have getRole call it to get the validRoles value instead.

@@ -1687,7 +1695,15 @@ lookupTable.role = {
nameFrom: ['author'],
context: null,
implicit: ['input[type="search"]'],
unsupported: false
unsupported: false,
allowedElements: [
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

General question: How did we miss this, and how do we know we're not missing more stuff this time around?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the holy grail source of truth - https://www.w3.org/TR/html-aria/ to construct these mappings.

There are 3 caveats with this:

  1. Misinterpretation.
  2. Conformance between ARIA1.0 and ARIA1.1, that was the case with aria-allowed-role with custom autocomplete (combobox + listbox, aria 1.0 vs aria 1.1) (PR #1118) #1116. There were multiple ways to use a role. 1.1 mandates usage of role on parent, but backwards compatibility with 1.0 means role can be set on said element itself.
  3. When https://www.w3.org/TR/html-aria/ is updated, we need a handle to confirm that things have not been changed, and adapt to new changes. Perhaps can watch/ github hook for the same and streamline the mapping.

To answer your specific Q, we missed this case due to an overlap of 1 and 2 above.

I am going through the table once more to ensure the mappings are right.

});

// filter invalid roles
const validRoles = roleSegments.filter(role => isValidRole(role));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

getRole already filters out invalid roles, doesn't it? Couldn't you just do this:

return getRole(node, { noImplicit: true, dpub: true }) !== null

@@ -7,7 +7,6 @@
<section id="pass-section-role-doc-bib" role="doc-bibliography"></section>
<ul><li id='pass-li-role-doc-biblioentry' role="doc-biblioentry"></li></ul>
<aside id='pass-aside-doc-example' role='doc-example'></aside>
<div id='pass-div-has-any-role' role='divAnyRoleEvenInvalid'></div>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of removing, I suggest you put in a valid role.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. Added it back again. This diff only watches this line, so comment is not going stale.

@jeeyyy jeeyyy dismissed WilcoFiers’s stale review September 5, 2018 09:17

Updated. Review welcome.

@@ -71,6 +37,12 @@ aria.getElementUnallowedRoles = function getElementUnallowedRoles(
return true;
}
}

// if role and implicit role are same, it is redundant - ignore
if (role === implicitRole) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm confused about why you're doing this for a second time. Line 28 already tests for implicit roles, correctly taking the allowImplicit option into consideration.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right, that flow path, only handles the edge case for table>tr[role='row']. I shall refactor.

* @returns {Array} Roles list or empty list
*/

aria.getRoleSegments = function getRoleSegments(node) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Either add tests for this, or don't move this into a commons. My preference would be the latter. I think you've made this PR much larger than it needed to be for the fix.

Copy link
Contributor Author

@jeeyyy jeeyyy Sep 6, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There were tests (dcacb51#diff-c01d2c9028bf4f6a16bace64d8ce59daR1) indeed . They were at the bottom of the PR. I needed to use getRoleSegments in 2 places, one within the matches, the other within the check, hence the abstraction to commons.

But believe I could use getRole in matches.

Will remove aria.getRoleSegments

@jeeyyy jeeyyy dismissed WilcoFiers’s stale review September 6, 2018 09:36

Updated. Reviews welcome.

@jeeyyy
Copy link
Contributor Author

jeeyyy commented Sep 7, 2018

@WilcoFiers - reviewer checks were not filled up. Doing it on your behalf.

@jeeyyy jeeyyy merged commit a0f9b31 into develop Sep 7, 2018
@jeeyyy jeeyyy deleted the fix-aria-allowed-role branch September 7, 2018 07:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants