accessibility guide

[Alex-Jordan]

This has issues, and I need to ask for everyone's (@drgrice1, @pstaabp, @somiaj, @dlglin) input to make this acceptable for a first release. Anyone else who wants to jump in? (@dpvc, @taniwallach, @glarose?) Perhaps it is easiest to contribute to this just by making a GitHub suggestion. But PRs to my branch are welcome.

This started out as a Claude-built summary of WeBWorK's accessibility. It was not great. I rewrote almost all of it except for the "Guidance for problem authors and editors" section. In that section, I added a thing or two, removed several things, and left other things as Claude wrote them even though I know they are bad. I'm especially wary of the graphTool section. The problem is I'm struggling to describe to people well how they should go about writing problems well, and even more with how to tell people how to convert existing problems to a more accessible form. I'm wondering if those of you who have worked more with the editor could take a stab at those sections. There is the conversion tool to PGML. The PG critic. The various links to sample problems, PGML help, and POD.

[drgrice1]

On the graphTool, this states that it has no non-visual interaction model, and that is NOT true anymore.

[drgrice1]

Also, on the Plots::Plot usage, how is using that with a good alternate text any different than using a static image with a good alternate text? I don't think that this should discourage using the Plots::Plot approach. Note that Plots::Plot does not generate interactive graphs.

[Alex-Jordan]

Those are the areas in particular that I left as Claude wrote them, knowing they are bad. I'm expecting them to be removed or replaced, I just don't know what to say if there is still anything to say. Are there known accessibility cautions to give about using either of them? I guess I should have just cleared the Claude text and left placeholder text.

[drgrice1]

I do not know that the functionality of the graphTool is perfect, and I am certain it will still need more work. But just saying it is not accessible completely defeats the purpose of the work that I recently did on it.

[Alex-Jordan]

For GraphTool, do you think one of the following options are good?

• Remove mention of GraphTool.
• Write about how GraphTool has had recent accessibility improvements, and we expect it to be largely accessible. But field testing reports are welcome.
• Write about how GraphTool has had recent accessibility improvements with respect to keyboard operation, but non-sighted users may still have difficulty.

Or you can make an edit as a suggestion in the diff, and I'll just approve it.

[drgrice1]

@Alex-Jordan: I think that the second option for the GraphTool sounds right.

[Alex-Jordan]

@Alex-Jordan: I think that the second option for the GraphTool sounds right.

OK, I'll make an edit like that and push soon.

[somiaj]

I would suggest updating the information on alt tags and clarify that it is for static images. For graphs generated using PGgraphmacros.pl graphs or PGlateximage.pl/PGtikz.pl graphs, mention these just generate static images which follow the alt tag guide lines. But for generated graphs, I would encourage the use of using plots.pl to generate generate graphs with its default jsxgraph output. In that case the alt tag isn't really an alt tag, it is an aira-description which won't have character limits and unsure of the long_description is something that is needed for that.

[Alex-Jordan]

I would suggest updating the information on alt tags and clarify that it is for static images. For graphs generated using PGgraphmacros.pl graphs or PGlateximage.pl/PGtikz.pl graphs, mention these just generate static images which follow the alt tag guide lines. But for generated graphs, I would encourage the use of using plots.pl to generate generate graphs with its default jsxgraph output. In that case the alt tag isn't really an alt tag, it is an aira-description which won't have character limits and unsure of the long_description is something that is needed for that.

Could I invite you to write what it should say, and either suggest that here in GitHub, or open a PR to my branch? This accessibility guide surveys so many things (like plots.pl) that I don't know much about.

[dlglin]

Should we be including what accessibility checks WW has passed? We should be able to say something about the interface meeting accessibility standards of certain automated checkers as of the 2.21 release.

[Alex-Jordan]

Should we be including what accessibility checks WW has passed? We should be able to say something about the interface meeting accessibility standards of certain automated checkers as of the 2.21 release.

By all means, please do :)

I don't have time to conduct a thorough review. I don't want to write "WeBWorK conforms to WCAG X.Y level Z" without actually checking everything in that standard. But I don't mind if someone else wants to.

[somiaj]

Here is my stab at updating the description for image descriptions. I also fixed some typos and limited the character width to 79 characters.

accessibility-diff.txt

[Alex-Jordan]

Thanks @somiaj, I added that to the branch.

[taniwallach]

I quickly read over the material. I think it gives a good overview of matters, and regardless of how complete it is, I would certainly think it would be good to merge it in before the release.

It might be worth mentioning that to a great extent, webwork problems depend on the student using the context in which an input box appears to determine what is expected there. In particular, input boxes are often interleaved into pieces of a mathematical expression, and their location implies what they are. This can include being a coefficient of a term, a "missing" term in an expression, etc. This is almost certainly not strictly in compliance with WCAG. However, just as a sighted user needs to make the necessary determination from the context, so does a screen-reader user.

In several local problems where input boxes are laid out visually (ex. limits of integration using CSS grid tools) and some questions with other less accessible features - I have placed knowls into the question giving some explanations. It could be that a better approach would be to somehow add aria labels or the like to the input boxes, but I'm not sure how that could be done properly.

We have some problem where students are asked whether 2 dimensional regions are x-simple or y-simple. Giving a "verbal description" in this setting would essentially give away the answers. We decided to put in a recommendation that visually impaired students request help creating "cardboard" cut-outs of the regions - with the directions marked - since they could then use tactile senses to check the required condition. It may not be ideal, but such an approach allows the student to make the necessary determination.

[somiaj]

@drgrice1 Just a ping on seeing if we can copy the aria-label to MathQuill answer boxes. I tried to figure out how to do that myself, but don't quite understand the best place to integrate this with the MathQuill repository.

I would like to also add info on how to customize answer box labels in the accessibility guide as that can help with what @taniwallach mentioned of when multiple answer boxes are combined into a bigger answer. I use the labels in my integral answer checker for each box saying things like 'middle integral upper bound'.

[drgrice1]

I really haven't looked at this yet, but I am going to approve it anyway. It is something that is needed, and can be updated further as we go.

The base branch was changed.

[Alex-Jordan]

I made some edits and force pushed my branch. This is now retargeted to main for a hotfix.