Accessibility Issues in Wiki

[frankduncan]

Ok, so I used this really neat javascript tool called ANDI (https://www.ssa.gov/accessibility/andi/help/install.html) which looks at your webpages, and loaded up the macfound wiki. When looking at a page, the only violations on it were:

• The default table of contents wiki interaction is not accessibly friendly (the hide/show toc that appears on each page)
• The youtube iframes aren't properly labeled
• The text box as part of the comments isn't properly labelled

The last one is the only one that's really under my control to fix, as that's a plugin we're responsible for. Otherwise, things seem to pass just fine.

[kfogel]

We're responsible for all of it -- we're the ones who choose the tools we use :-). Now, we might decide that the cost/benefit of fixing something isn't worth it, but that decision is about difficult more than about module ownership per se. Regarding each of the three:

• The hide/show button (which toggles a hidden checkbox) for the TOC: We need to find out how serious a problem this actually is for which users. I will consult with some a11y experts.
• YouTube iframes (from the EmbedVideo extension): We should add the label locally, as a local modification, and then try to send the fix upstream. If upstream is inactive, well, okay, then that makes the fact that we've patched locally less problematic at least. Anyway, our course is clear here: we will fix this one in our production instance.
• Comments text box: Obviously we just fix that. Yay.

[frankduncan]

Ah! Some more stuff turned up as I learned to use the ANDI tool a bit better. The following are red alerts and so we should strongly consider fixing:

• The comments section fails the contrast ratio for things like "commented on XXX day" and "Deleted"
  • Should be easy to fix
• The table in the sidebar has no <th>
  • Easy to fix, but we have to decide whether this is a "presentation" table, or a "data" table. In the former, the fix is adding role="presentation" to the table. If the latter, we should come up with meaningful headers. I think it's the former, but wanted to double check.

The following are orange alerts, to may require discussion:

• All the hide/show section links (only available to admins) are noted as having the same "name" so screenreaders may get confused.
  • I think this isn't a need to fix.

[frankduncan]

YouTube iframes (from the EmbedVideo extension): We should add the label locally, as a local modification, and then try to send the fix upstream. If upstream is inactive, well, okay, then that makes the fact that we've patched locally less problematic at least. Anyway, our course is clear here: we will fix this one in our production instance.

I made the change locally, which was straightforward. When looking at patching to upstream, I noted that it was relatively active (as in, prs are getting merged as they come in every few months), and that master is actually a few (<10) commits above the 2.8.0 tagged version.

Moving forward we have a few options:

1. Create local tar of tagged version + my commit, deploy that
2. Create local tar of master at time.now() + my commit, deploy that
3. Use release tar (that we have checked in), then apply my patch after deploying
4. Use tar of master at time.now(), then apply my patch after deploying

I can come up with a cogent argument for each one of them.

Regardless of what we decide, I'll mail them the patch to see if they want to include it.

[kfogel]

@frankduncan has submitted this change to the upstream EmbedVideo project.

[kfogel]

We should run a released version + our custom patch until they release a version that has the patch (at which point we switch to that new version, of course). So for now, let's do option (3) above -- that way we keep the separation between upstream's published version and our change as clean as possible in the repository.

[kfogel]

Bruce Paul (whose GitHub handle I don't know) did some accessibility testing for us too. Here's the output (I've sent him email asking for details about the specific links and ALTKEY tags):

Web Site URL: https://wiki.opentechstrategies.com/lfc

Executive Summary

As of the last discussion I had with Frank about the state of the web site, I found the site useable for someone using adaptive technology. I highlighted two "errors" that would make it difficult to navigate the page. I also pointed out that the use of key-bindings inside tags would make the use of screen readers difficult, adding to a watch list with "ALT-SPACE-W," for example. If these problems are corrected, one could navigate the page easily with most screen readers.

All evaluation was based on rendered HTML in Firefox on Linux.

Specific Problems:

Errors:

Two(2) Links that don't have appropriate description, or
indication of what type of element they are. They also don't
indicate where they lead to. We recommend to place navigation
links at the top of the page with clear description of where they
lead.

Alerts:

Twenty(20) 'ALTKEY' Tags - for example 'ALT-SHIFT-W' to add to a
watch list. These tend to 'trap' screen reader shortcut
key-bindings
The site could have stronger contrast

References

WebAIM: https://webaim.org/
WCAG 2.0 Checklist: https://webaim.org/standards/wcag/checklist