WeBWorK Main Forum

Accessibility Team Tests WeBWorK: Results

Accessibility Team Tests WeBWorK: Results

by tim Payer -
Number of replies: 5
We at Humboldt State, one of 23 campuses of the California State University system just had an "Accessibility team" test WeBWorK for accessibility.

Here are their Findings:

1.) Entry Cells need to be flagged with some type of html code to flag what the contents of each entry cell is supposed to contain: for example "Answer to problem 1c", or "square root of MSW" or "probability for P(x)".

2.) The "Results for this submission" grid that appears at the top of the page after one hits the "Check Answers" button should have an additional column before the columns of "Entered", Answer Preview", "Result" and "Correct Answer". This new column would identify the problem number within the assigned problem. I realize that most Webwork problems only have a few entries so this would not be needed for the majority of problem, but if one has over a dozen entries for an assigned problem, a row descriptor for the first column would be desired for the accessibility folks.

3.) The signature footer at the bottom of each Webwork page: “Page generated at 12/21/2019..." needs to have its font size increased or be placed against a background with greater contrast.

The other recommendations were easier fixes that could be attended to by the user: All tables needs headers for example, caption text alone does not suffice.

Any feedback for this is most appreciated.

Best, Tim
In reply to tim Payer

Re: Accessibility Team Tests WeBWorK: Results

by Michael Gage -
Hi Tim,

Thank your accessibility team for doing this.

1. If I've understood you correctly this type of flagging would need to be done in the problem code -- for each problem since there would be so much variability for each problem.

2. This could be done at the system level and would benefit everyone, particularly on things like matrices. I'm not sure of the best way to do it. There is an internal numbering systems for the problems which is mostly sequential except when an author has chosen a "NAMED" answer blank. Posting that would be better than nothing, but perhaps something even better could be devised. I'll be happy to help code the solution once there is a consensus on the best way to improve this indexing.

I've suggested a javaScript solution which displays errors and answers for a given answer blanks in a pop-up menu when the mouse hovers over the answer blank (e.g. an answer blank in a matrix). That would clearly be an improvement for sighted users navigating errors in a large matrix but it might actually be worse for accessibility. This would be a good project for someone who likes javaScript coding but doesn't want to get too involved in the core WeBWorK code.

3. We specifically chose the font-size and light gray color of the footer so that (a) it would not get in the way and (b) it was convenient for an instructor or anyone reporting bugs to tell what version of webwork they were using. I'm not sure of the best way to resolve this one -- we could remove it entirely, but it has proved quite useful for instructors and administrators in dealing with bugs. On the other hand students should be able to ignore it 99% of the time and I think it might be ok if screen readers ignored it as well.

You should get in touch with Alex Jordan at Portland Community College if you haven't already. He and the PCC accessibility office have put a lot of thought into WeBWorK accessibility:



In reply to tim Payer

Re: Accessibility Team Tests WeBWorK: Results

by Alex Jordan -
Hi Tim, and thanks for sharing these findings.

1.) Mike is right that this is more of a "content" issue than a "container" issue. WeBWorK could never automate these kinds of descriptions, but maybe WeBWorK could provide an easy way for a problem author to do this. When you say "entry cell", is that the input field where a student types an answer? There could be a hidden label element for each one. Problem authors could maybe do something like ans_rule(label=>"square root of MSW") or in PGML, [_]{$answer}{label=>"square root of MSW"}. There could be a default that uses "answer blank 1" where it gets the "1" logically.

2.) I was surprised to read this, because the HTML from an XMLRPC does have these numbers in a leftmost column. I've been working with that lately so I have it in my head those numbering labels are there. (As, say, here: https://spot.pcc.edu/math/orcca/ed2/html/section-variables-and-evaluating-expressions.html).

But after logging in to regular WeBWorK, yes, I see there is no leftmost column of number labels. I haven't looked into it, but it seems if it's there for the XMLRPC version, it shouldn't take much effort to get it there for regular WW use as well.

3.) I'm not sure that students should be distracted by seeing this stuff in the first place. What if the "WeBWorK © 1996-2019" stayed there, but became easier to read. And then there was something like "Developer information" that a user could click or otherwise activate to reveal the rest of the information that is currently there?


For this one:
> All tables needs headers for example, caption text alone does not suffice.

Was this referring to tables that WeBWorK (the "container") makes? Or tables within a particular problem? If it's the latter, it is the responsibility of the problem author (or a later editor) to see that the table is built accessibly. If there are more ways that WeBWorK itself can make that easier for the author/editor, we should make it so. Or did you find tables that the WW engine makes (as opposed to a PG problem) that need headers? An example of a table that the WW engine makes would be the results table mentioned in item 2. (But that one does have headers.)

In reply to Alex Jordan

Re: Accessibility Team Tests WeBWorK: Results

by Nathan Wallach -
At present - there is automatic generation of generic "aria-label" values which do not convey much real information. See the section "Interacting with Questions" at http://webwork.maa.org/wiki/Accessibility_Guide which says
However, in the case of something like a fill in the blank question, some input elements will simply be labelled as “answer input 1”.

I like Alex's proposal of adding a feature to allow problem authors to provide text which could be used to provide more detailed label information for the input boxes (and other answer controls), which would over time allow problems to provide better labels.

I'm opening a GitHub issue to propose doing this: https://github.com/openwebwork/pg/issues/444

I think that at the same time, it would help to code a more general extension mechanism for attaching extra data to input elements of all type. One additional use case would be the ability to allow attaching CSS style code to a specific input element in a manner which does not depend on "knowing" the "id" value which will be assigned to that element.

For example, I have recently been coding a few problems using the technique from http://webwork.maa.org/moodle/mod/forum/discuss.php?d=4462 to format the limits of integration nicely. However, at present - the approach requires determining the "id" assigned to each needed input box to attach the CSS code to it. This would be apparently be broken if a problem were loaded as a portion of a large problem if the "index numbers" could be different in different cases.

I would be happy to work with some other people on coding such a feature, but I cannot start work on it for a few weeks (until after my current semester commitments are completed).

Nathan
In reply to Alex Jordan

Re: Accessibility Team Tests WeBWorK: Results

by Nathan Wallach -
About:

2.) I was surprised to read this, because the HTML from an XMLRPC does have these numbers in a leftmost column. I've been working with that lately so I have it in my head those numbering labels are there. (As, say, here: https://spot.pcc.edu/math/orcca/ed2/html/section-variables-and-evaluating-expressions.html).

In the code of lib/WebworkClient/ptx_format.pl there is an inclusion of "$answerhashXML" and lib/FormatRenderedProblem.pm defined
my $answerhashXML = XMLout($rh_answers, RootName => 'answerhashes');
so I suspect that the # column is being added by preTeXt and not really generated by WeBWorK directly.

The sample Alex provided also has links in the "Results" column which call things like:
javascript:document.getElementById("AnSwEr0001").focus()
which is not part of the standard WeBWorK table.

I agree that it would be nice for accessibility and for regular use to add such an "index" column to the regular answer table, possibly where the "index" could be a "in page location link" to the (first) relevant input element (first needed for MultiAnswer and Matrices, etc.) (I suspect that making the index a link rather than the "Result" might be easier to implement.) We could probably use a combination of JavaScript "scrollIntoView()" and "focus()" and not just "focus()".

Such a feature would also help better satisfy:
We will need to make sure to follow the WCAG recommendations about how/when a change in context is initiated, so some (aria based?) indication is needed that the link moves the focus and scrolls the screen would be needed.
In reply to tim Payer

Re: Accessibility Team Tests WeBWorK: Results

by Nathan Wallach -
Tim - Thanks for sharing this feedback. Supposing work was done on adding features to address these issues, would the "Accessibility team" be able to provide feedback on changes made to test sites?

About the page footer info:
  • 3.) The signature footer at the bottom of each Webwork page: “Page generated at 12/21/2019..." needs to have its font size increased or be placed against a background with greater contrast.
  • 3. We specifically chose the font-size and light gray color of the footer so that (a) it would not get in the way and (b) it was convenient for an instructor or anyone reporting bugs to tell what version of webwork they were using. I'm not sure of the best way to resolve this one -- we could remove it entirely, but it has proved quite useful for instructors and administrators in dealing with bugs. On the other hand students should be able to ignore it 99% of the time and I think it might be ok if screen readers ignored it as well.
If this is really only for instructors and administrators maybe it could be hidden away inside an HTML comment and not displayed to the students. Alternately, provide a visible button to show "internal server data for debugging purposes" and then make it visible as an alert box / popup window / knowl which would not be visible by default.