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(a11y-wand): add handling of nested aria-hidden elements #134

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ericrallen
Copy link

We needed to set the recursive argument in the findTextAlternatives() method to true so that accessibility-developer-tools would check for nested hidden elements.

This also adds two simple tests to make sure that this functionality isn't broken in the future.

Closes #133

@khanbot
Copy link

khanbot commented Mar 9, 2019

Hey @ericrallen,

Thanks for the PR! Mind signing our Contributor License Agreement?

When you've done so, go ahead and comment [clabot:check] and I'll check again.

Yours truly,
khanbot

@ericrallen
Copy link
Author

[clabot:check]

@khanbot
Copy link

khanbot commented Mar 9, 2019

CLA signature looks good 👍

@@ -20,6 +20,7 @@
"handlebars-loader": "^1.0.0",
"jquery": "^2.1.3",
"jsdom": "^8.1.0",
"jsdom-global": "^2.1.1",
Copy link
Author

Choose a reason for hiding this comment

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

This seemed to be necessary to get the a11y-text-wand plugin to run due to needing to access something on window that wasn't available without jsdom-global.

Copy link
Contributor

Choose a reason for hiding this comment

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

Do you recall what it was that was missing?

Copy link
Author

Choose a reason for hiding this comment

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

I'll pull it out run the test again and report back.

Copy link
Author

Choose a reason for hiding this comment

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

Without jsdom-global:

ReferenceError: window is not defined
      at InfoPanel.initAndPosition (plugins/shared/info-panel/index.js:127:9)
      at InfoPanel.render (plugins/shared/info-panel/index.js:346:18)
      at A11yTextWand.run (plugins/a11y-text-wand/index.js:23:20)
      at Context.<anonymous> (test/a11y-wand-test.js:29:16)

I'm not super familiar with jsdom, but some brief research lead me to the jsdom-global and --require jsdom-global/register solution for resolving this error.

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks for checking into that. This is not a request for you, just an outloud musing; I wonder if upgrading jsdom as well as setting pretendToBeVisual to true in its setup would address this too.

Copy link
Author

Choose a reason for hiding this comment

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

A quick glance at the jsdom docs seem to indicate that might be the case. It looks like the usage of jsdom has changed a good bit and jsdom.env no longer exists and this change might require some more significant refactoring.

This same error shows up for all four of the tests this PR adds and none of the other tests run.

 1) Screen Reader Wand "before all" hook:
     TypeError: jsdom.env is not a function
      at Object.exports.createDom (test/mock-dom/index.js:30:11)
      at Context.<anonymous> (test/a11y-wand-test.js:12:17)

Copy link
Author

Choose a reason for hiding this comment

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

I misspoke, it does try to run all the tests, but they all fail with the same error from above.

Copy link
Author

Choose a reason for hiding this comment

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

I spent a little time trying to quickly refactor the mock-dom file, but it looks like something with how the annotations are handled might be causing an issue?

I don't think I'm familiar enough with jsdom or the way this is being handled to resolve it without a good deal more research.

Copy link
Contributor

Choose a reason for hiding this comment

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

I can work on upgrading JSDOM, if you'd like. I have quite a bit of experience with it if late. I can put you on the review and we can collaborate so that all gets landed.

I've already been upgrading other dependencies yesterday, so this fits pretty well with that.

What do you think?

Copy link
Author

Choose a reason for hiding this comment

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

Sure thing.

We can put this one on pause and rebase once the JSDOM updates are merged in.


let textAlternative = axs.properties.findTextAlternatives(
element, {});
element, {}, true);
Copy link
Author

Choose a reason for hiding this comment

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

This was the real fix to the issue, the true tells findTextAlternatives to run recursively on the Element and it's children. Without this, nested aria-hidden elements will show up in the Screen Reader text that is displayed in tota11y's info panel.

@ericrallen
Copy link
Author

@somewhatabstract I know this repo hasn't been touched in quite awhile, but this is kind of a big issue with how the a11y-text-wand operates. There are a few PRs that have been sitting out there for awhile. Is there anything we can help with to get this or any of the other PRs across the finish line?

@somewhatabstract
Copy link
Contributor

somewhatabstract commented Mar 13, 2019

@somewhatabstract I know this repo hasn't been touched in quite awhile, but this is kind of a big issue with how the a11y-text-wand operates. There are a few PRs that have been sitting out there for awhile. Is there anything we can help with to get this or any of the other PRs across the finish line?

Hey, @ericrallen, thanks for pinging me and for contributing! I will make sure to put time aside this week so we can get this reviewed and merged. We are working on how to better manage our open source like tota11y; I'm sorry it's been a sub-optimal experience for this repo of late. I would like to contribute more and get tota11y on a regular update cadence; I'll work to get some time to do that.

Thanks again for reaching out.

@somewhatabstract somewhatabstract self-requested a review March 13, 2019 17:28
Copy link
Contributor

@somewhatabstract somewhatabstract left a comment

Choose a reason for hiding this comment

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

Thank you again for this contribution, @ericrallen. I've left some comments inline. Let me know what you think.

@ericrallen ericrallen force-pushed the feature/a11y-wand-aria-hidden branch from 07d1068 to 0887719 Compare March 15, 2019 23:37
@ericrallen
Copy link
Author

@somewhatabstract Thanks for taking a look. I believe I've addressed everything in your comments, but had one question about the testing AAA comments.

@ericrallen ericrallen force-pushed the feature/a11y-wand-aria-hidden branch 2 times, most recently from 0ced4a0 to e184248 Compare March 16, 2019 03:12
@ericrallen ericrallen force-pushed the feature/a11y-wand-aria-hidden branch from e184248 to 2841a42 Compare April 15, 2019 19:30
@somewhatabstract
Copy link
Contributor

I haven't forgotten this. I will try to make time this week to give feedback. Thank you for your patience.

@ericrallen
Copy link
Author

No worries. I know how easy it is to get busy with stuff.

I see there were more changes merged in so I'll resolve the conflicts and get this conflict-free, too.

@somewhatabstract
Copy link
Contributor

Thanks for your patience, @ericrallen.

I'll work on the JSDOM upgrade today, but I think this is looking pretty good otherwise. It needs rebasing to the latest master as we're no longer committing build artifacts (yay!).

@ericrallen
Copy link
Author

@somewhatabstract Rebase is taken care of. Looking forward to the JSDom upgrade and getting this one merged in.

Thanks for taking a look. I know it's tough to find time for this stuff when things get busy.

@somewhatabstract
Copy link
Contributor

@somewhatabstract Rebase is taken care of. Looking forward to the JSDom upgrade and getting this one merged in.

Well, I spent a few hours with this today. Just updating JSDOM was a journey since its API has changed, making the way we import files more difficult. I thought I'd see if I could leverage jest and its use of JSDOM to make things work, but that proved difficult. It changed how things were getting imported leading to different behavior from axs. I'd rather remove hacks than add more, so I'm a bit reluctant to just hack it to work. I'm going to think about it some more and see if we can get a path forward.

Thanks for taking a look. I know it's tough to find time for this stuff when things get busy.

No worries. I am really sorry for taking so darn long. Thank you so much for being patient and for making contributions to this project.

@somewhatabstract
Copy link
Contributor

somewhatabstract commented May 18, 2019

If you have chance to look at what I'm looking at @ericrallen, it's this.

  1. At the CLI, run node REPL.
  2. const axs = require("accessibility-developer-tools")
  3. And then just show what that looks like; you should see it's missing a whole bunch of things like AuditRules

If you do the same inside of our tests or the browser, then all those things are there.

This different behavior in the two worlds is making it difficult to move forward with the JSDOM update. My current thinking is that we may want to remove our dependency on this no longer maintained library. Not an insurmountable task but definitely weightier than I envisioned when I first said we should update JSDOM.

So, I'm going to roll back on that suggestion for now and let's move forward with jsdom-global as you need it for this work (and it's only for our test environment).

We should then strategize how we can deal with our hard dependency on accessibility-developer-tools.

@somewhatabstract
Copy link
Contributor

I think I know how to resolve this after all. I'll try to get a PR together.

We needed to set the recursive argument in the findTextAlternatives method to true so that accessibility-developer-tools would check for nested hidden elements.

This also adds two simple tests to make sure that this functionalit isn't broken in the future.

Closes jdan#133
@ericrallen ericrallen force-pushed the feature/a11y-wand-aria-hidden branch from ee94325 to e70cd13 Compare May 19, 2019 13:52
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.

Elements with aria-hidden="true" still included in output of Screen Reader Wand
3 participants