Accessibility Issues in Wiki #9

Activity

1. kfogel commented on Oct 21, 2019

   

   kfogel

   on Oct 21, 2019

   Last edited by kfogel

   Member

   More actions

   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.
2. frankduncan commented on Oct 23, 2019

   

   frankduncan

   on Oct 23, 2019

   CollaboratorAuthor

   More actions

   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.
3. frankduncan commented on Oct 23, 2019

   

   frankduncan

   on Oct 23, 2019

   Last edited by frankduncan

   CollaboratorAuthor

   More actions

   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.
4. kfogel commented on Oct 23, 2019

   

   kfogel

   on Oct 23, 2019

   Last edited by kfogel

   Member

   More actions

   @frankduncan has submitted this change to the upstream EmbedVideo project.
5. kfogel commented on Oct 23, 2019

   

   kfogel

   on Oct 23, 2019

   Member

   More actions

   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.
6. frankduncan

   added a commit that references this issue on Oct 27, 2019

   Fix textbox names for accessibility reasons.

   ...

   b806971
7. kfogel commented on Jan 11, 2020

   

   kfogel

   on Jan 11, 2020

   Member

   More actions

   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