Discussion: Editor and Documentation Accessibility

[cmoody]

Howdy,

This issue is designed to open up a discussion about the accessibility in GraphiQL. Currently at Vrbo we have a team member who is blind and since most tooling is not accessible first, it makes it difficult for them to both learn and utilize GraphQL to its fullest.

I wrote the title as Editor and Documentation because I think each could have their own challenges as we look at what is needed.

Editor:
I did a quick test of a few screen readers. For the most part all of them get stuck in the editor with no way out. This could also be due to my lack of knowledge around screen readers so warrants more investigation.

Documentation:
It was hard to test this too much because it tended to toss me back into the editor. I think GraphQL lends itself nicely to make documentation a wonderful experience. Having good descriptors on moving from parent to child I think will make navigating through a breeze.

Im a novice when it comes to accessibility but hope to help out and my team member is up for testing out any features.

[acao]

thanks @cmoody for reporting! I'll be sure to check it out in greater depth this weekend.

[acao]

It looks like Codemirror 6 would introduce some improvements for the editor:
codemirror/codemirror5#4604

However, its not certain when that will come out, and we will be switching to Monaco in a few months anyways

[Neitsch]

@cmoody, accessibility is important for GraphiQL to be inclusive. I appreciate that you file this issue. Are you / your coworker aware of how to approach this problem? I recall that there are some linters to help a11y compatibility.
Anything that would help us have a more structured approach would be appreciated!

[acao]

in my experience, the linters can only do so much. for example in react, we can lint the static prop names of components but not values before theyd been cast. So a linter like a11y is great to catch things statically, but then you need to do runtime checks in CI, there are tools we can use with or alongside e2e suites, and thatll help us keep track of many more issues. So I would say first step is an end to end suite, and adding the linter, and then adding a more comprehensive check against, say, our netlify@next that maybe even gates against accessibility debt introduced in a PR. I architected something like this for the new medicaid/medicare patient enrollment forms when i was consulting for CMS in baltimore. 508 had just synced up with WCAG2 at that point, so im quite familiar with using that as a standard.

[acao]

Here's a really cool example, wish we had this then!
https://github.com/cypress-io/cypress-example-recipes/tree/master/examples/blogs__a11y

Again, this is just the first step, of catching and documenting these issues, the greatest effort will be in resolving them.

[acao]

@cmoody hey there! so we have released a version that should have some substantial accessibility improvements, big thanks to @kasperisager for making such a huge first-time contribution for this! If your colleague has a chance to review that would be splendid. In the time being, I'll set up the automated suite above to prevent accessibility debt in the future.

[acao]

I won't close this ticket until we can ensure that they and other folks who use non-sight based browsers are able to use all the GraphiQL features. Unfortunately the remaining issues from my cursory audits, after the spike, seem to be built into codemirror