Matching problem updated for accessibility

[Colin Fredericks]

HI everyone.

If you're using the Matching problem I created a while ago (it's a custom javascript type), you should almost certainly upgrade to this new one:

https://github.com/Stanford-Online/js-input-samples/tree/master/matching_accessible

It keeps all the functionality from the old drag-and-drop matching type, and adds a separate view that is accessible to blind and partially sighted folks who are using a screen reader. There was also a little code refactoring and cleaning. The old version is still in the repository but is officially listed as "deprecated."

I've tested it with VoiceOver on Mac. I'd love to hear how it works on other screen readers.

[msad...@edx.org]

Hey this is great!  Glad to see an attempt at making a notoriously inaccessible problem type a bit more accessible.  I tested with both Voiceover on MAC and NVDA and JAWS on Windows and have a bit of feedback and/or food for thought:

Ideally, you never want an "alternative" version if you don't need one, and I think the interaction pattern used in the accessible version here can actually be merged nicely with the primary experience.  The use of repeating sets of checkboxes in the accessible version is very clever indeed.  Why not include these as hidden elements (offscreen) for the screen reader user.  The set of checkboxes would follow each of the items in the left hand column.  The user would move from the description in the left column, directly to the set of checkboxes that represent the choices in the right column, and then they would move right on to the next description and repeat.  You could then add an aria-hidden to the choices in the column on the right, hiding them from the screen reader.  This would eliminate the need for an alternative version.

RE the current implementation: Most screen reader users on the Windows platform will use the TAB key to move from form field to form field when they encounter a form, which makes them very likely to miss text presented anywhere outside of form field and label elements, which in this case, includes the stuff in the left hand column.  The implementation as it stands might be improved by adding an aria-describedby that points to the relevant text in the left column, to programmatically associate that expanded text with the fieldset for the checkboxes that is used on the right.

Thoughts?

Mark

[Colin Fredericks]

Thanks for the feedback! I'm very much a novice at this and I appreciate the help.

That's an interesting idea about the hidden elements; I never would have thought of that. I'm always a little concerned about "hidden but not actually hidden" solutions, but if that's a standard approach I might try that out.

I can easily add the aria-describedby attribute, but I'm not sure what to add it to - the form, the fieldset, the legend, or the individual input elements?

[msad...@edx.org]

On Thursday, October 9, 2014 6:16:45 PM UTC-4, Colin Fredericks wrote:

Thanks for the feedback! I'm very much a novice at this and I appreciate the help.

That's an interesting idea about the hidden elements; I never would have thought of that. I'm always a little concerned about "hidden but not actually hidden" solutions, but if that's a standard approach I might try that out.

It's a very standard approach for providing content specifically for screen reader users (as long as you are sure the content is *only* applicable to that audience).  Hearing myself say that makes me realize that *your* solution was *also* keyboard accessible, which helps sighted keyboard only users...  Perhaps there is a hybrid solution where toggling accessible mode replaces the objects in the DOM in the right hand column with the offscreen forms...  Something to think about.
 

I can easily add the aria-describedby attribute, but I'm not sure what to add it to - the form, the fieldset, the legend, or the individual input elements?

Here is what I would recommend: Nobody likes using fieldset, especially if the value is potentially long.  Get rid of fieldset and legend and replace it with <div role="group" aria-labelledby="element[X]">  <!-- note change to aria-labelledby from aria-describedby, the support and experience was better.

This has the same effect as the fieldset>legend but points to the original content in the left column as the "legend".

Mark
 

[Shira Fruchtman]

Hi Colin,

A course team at MIT tried using the Matching Problem instead of the inaccessible drag and drop problem currently on edX. But they had issues with students complaining about answers not being saved. It appears to be an issue on Firefox when using the accessible (checkbox) version. After choosing the answers and clicking Check, the checkbox submissions disappear.  When I tested it, I was able to look at the Submission History and it looked as if the answers were never clicked to begin with (yet it does use an attempt). I'm not sure if this problem is still being worked on/updated, but if so, someone may want to look into this.

Thanks!

Shira Fruchtman

Educational Technologist, MITx

[Colin Fredericks]

Thanks for the info. I had someone complain about a similar issue during the last run of my course. If they're using a version of the code from before Nov 3rd, they might be able to fix this just by updating their MatchingA.js file to the newer version.

https://github.com/Stanford-Online/js-input-samples/tree/master/matching_accessible

If they're working with the current version, I'll see what I can do to fix it. Just let me know.

--
You received this message because you are subscribed to a topic in the Google Groups "General Open edX discussion" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/e593abe3-299a-46cf-8a8b-bbe6ba578664%40googlegroups.com.

[Daniel McQuillen]

Hi Colin,

A question about the "check" process within the larger problem XBlock when using this example or others from the Stanford/js-input-samples repo:

I noticed in the example projects that the iframe gets refreshed when the user clicks the problem's "Check" button. Do you know if there's a way to prevent that refresh cycle, or is it a required part of the check process when using JS input? 

BTW, after watching your informative talk on XBlocks from a couple months back and taking the sample code for a spin, I was able to get started really quickly. Thanks for sharing your knowledge!

Thanks,

Daniel

[Colin Fredericks]

I'm fairly sure the refresh is an inherent part of JSInput problems. I use the SetState function to make sure everything is back the way it was before, so students just see the flicker and not a total reset.

I'm glad it was helpful to you! Last I talked with Stanford they were happy to have more JSInput problems added to that repository, so if you are able to share your code, please do.

--
You received this message because you are subscribed to a topic in the Google Groups "General Open edX discussion" group.

To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/34d4dfa4-aa09-4031-9cd3-2f002da2b1ff%40googlegroups.com.