Spike: Investigate and apply accessibility reqs. to the dataset page

[TaniaSchlatter]

This spike is to learn about and practice applying accessibility best practices to an existing page.
Outcomes:

• Identification of standards that are most relevant to Dataverse design and development (see draft below)
• Identification of tools and resources we can use to help us improve accessibility (some included below)
• Identification of changes to design and development processes that will help us improve accessibility
• More accessible code for the dataverse page
• Better position for working with automatic testing processes

Informational resources:

1. Conceptual overview of WCAG
   For the purposes of Harvard’s Digital Accessibility Policy, the University uses the Worldwide Web Consortium’s Web Content Accessibility Guidelines version 2.1, Level AA.
2. Easy checks and methods to address: "Easy Checks - A First Review of Web Accessibility" recommended by the Harvard Library usability group.
3. Standards in detail, methods, and measurements: How to meet WCAG 2.1 from W3C WCAG group.

---

Links to detailed guidelines on the W3C site that are most relevant to the Dataverse application (not the content users add/upload):

Guideline 1.1 – Text Alternatives
Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.

Guideline 1.3 – Adaptable
Create content that can be presented in different ways (for example simpler layout) without losing information or structure.

Guideline 1.4 – Distinguishable
Make it easier for users to see and hear content including separating foreground from background.

Test color contrast with this tool: https://github.com/ThePacielloGroup/CCA-OSX/releases/tag/2.4

Guideline 2.1 – Keyboard Accessible
Make all functionality available from a keyboard.
How to test | Harvard-only slides of how to check and ARIA tags

Guideline 2.4 – Navigable
Provide ways to help users navigate, find content, and determine where they are.

Guideline 2.5 – Input Modalities
Make it easier for users to operate functionality through various inputs beyond keyboard.

Guideline 3.2 – Predictable
Make Web pages appear and operate in predictable ways.

Guideline 3.3 – Input Assistance
Help users avoid and correct mistakes.

Guideline 4.1 – Compatible
Maximize compatibility with current and future user agents, including assistive technologies.

[TaniaSchlatter]

We'll review initial status in the design meeting Sept. 4.

[mheppler]

Inventory of accessibility issues created as a result of exploring these new tools.

• Images - Add/improve alt text, link title, components Images - Add/improve alt text, link title, components #6106
• Metadata Labels - Review use of label tag outside of form (viewMode) Metadata Labels - Review use of label tag outside of form (viewMode) #6109
• Code Cleanup - i tag used for icons bad practice Code Cleanup - i tag used for icons bad practice #6144

[mheppler]

Comments from @kcondon and @TaniaSchlatter were compiled into this outline.

PROGRESS REPORT
++++++++++++++++

1. standard Harvard uses for accessibility (https://accessibility.huit.harvard.edu/policies)
2. plan for compliance, including date (December 1, 2019)
3. tools we use as part of a specific accessibility check (e.g. AMP, Siteimprove/Chrome extension, ++color contrast++; https://accessibility.huit.harvard.edu/tools)
4. strategy for addressing current and future accessibility issues

TO-DO
++++++

• Siteimprove report
• AMP report
• VoiceOver manual user test (https://help.apple.com/voiceover/mac/10.14/)
• Compile and review reports, create/group accessibility issues found on dataset pg
• Describe recommended process/knowledge/tools used to evaluate accessibility going forward for our development team and community

FOLLOW UP
++++++++++

1. discuss with team/Danny how to incorporate tools into dev/QA process
2. share accessibility tips/resources/expectations with community members

[djbrooke]

@mheppler @TaniaSchlatter @jggautier thanks for the post-standup discussion about this.

@mheppler, the plan we discussed made sense to me, please feel free to summarize here and close. I'll be happy to work with you in #6106 and other issues to facilitate the knowledge sharing (dev guide or other) as mentioned in the final checkbox above.

[mheppler]

I finally managed to squeeze out a manual report of the dataset pg in AMP, which checked off the to-do above. That left outlining the "process", and to deliver on that, I have added a new "Accessibility Testing" section to the Testing pg in the Developer Guide (see PR #6218).

The impact of accessibility on our development process will be evolving as we learn more about the tools, and requirements. The image alt text issue #6106, will provide out team a "proof of process" of sorts.

Reports from Siteimprove and AMP both caught this issue on the dataset pg, and when developing a fix, the browser tools from Siteimprove, AMP and Wave will all be checked, to make sure a suitable solution is implemented. Then once a pull request is submitted and approved, a test plan will be reviewed with @kcondon and @djbrooke to make sure QA knows not only what to test, but how to test.