Revise to improve accessibility

[wes-brooks]

I'm working to improve the accessibility of this workshop (with others to follow). This process begins by reviewing the workshop against the W3C Web Content Accesility Guidelines (WCAG). There are 13 guidelines under four categories, and each guideline has accompanying test(s). The W3C also suggests techniques to address the guidelines.

The guidelines are:

Perceivable

• Provide text alternatives for non-text content.
• Provide captions and other alternatives for multimedia.
• Create content that can be presented in different ways, including by assistive technologies, without losing meaning.
• Make it easier for users to see and hear content.

Operable

• Make all functionality available from a keyboard.
• Give users enough time to read and use content.
• Do not use content that causes seizures or physical reactions.
• Help users navigate and find content.
• Make it easier to use inputs other than keyboard.

Understandable

• Make text readable and understandable.
• Make content appear and operate in predictable ways.
• Help users avoid and correct mistakes.

Robust

• Maximize compatibility with current and future user tools.

[wes-brooks]

I also asked Katherine Brafford to review the workshop since she uses a screen reader. Here are the unedited notes I made during our conversation as she reviewed the workshop:

Katherine's thoughts:

• Use JAWS screen reader
  • NVDA: free and fairly good - probably the best for testing
  • Narrator is windows' built-in: almost nobody uses it
  • Talkback and Voiceover on Mac both good
• "Good that we use headings"
  • Seem to be in right plae and level
  • Jump between by "h" and keypad numbers for heading levels
• Fore and back are links like other links on page
  • Better to have "next" and "back" buttons rather than links
• Link labeling:
  • link list has a lot that are called, e.g., "here" and "anchor"
• Images
  • Many not labeled
  • Ch 1.2: description behind first graphic literally describes image, which is a repeat of figure caption
  • Next is following "You can make R compute the sum by typing the code 2 + 2 after the prompt and then pressing the Enter key. Your code and the result from R should look like this:" and is an image of R saying 2 plus 2 is 4.
  • Katherine prefers text over images, but the image at least needs a description
• There should be
• "Script error"s abound, seem related to math
• Search bar should be called search and have a text description that gives an idea of what it does
• The table of contents being split makes it hard to navigte and use.
  • ToC has a heading level but the chapter list does not, makes it harder to find the navigation buttons
• Good to have "Navigation" heading so it is findable from link list
• "Form field" inputs: not very useful because there are no many "copy to clipboard"
• Katherine likes button (not link) for next and back
• Katherine prefers gt() function over print.df()
• Can we get an alternate text description of tables (e.g. Section 3.1.2)? The reader doesn't make sense when encountering text tables (this is why Katherine uses gt()).
• Paragraphs are broken up in a weird way: 3.1.2 "DATA[ROWS, COLUMNS] For instance, let’s get the first 3 rows and all columns of the banknotes data:" is one paragraph. Also, this red box is one paragraph:

Lists that the reader can call up

• Form fields: "chunk of stuff" - some sites are organized heavily by form field
• Links
• Images
• Headings

[wes-brooks]

We currently have three sections labeled "navigation": The Table of Contents on the left, the chapter headings list on the right, and the buttons to go to the next or previous sections on the bottom.

[nick-ulle]

Thanks for working on this! Please make changes via PRs and let me know if there's anything I can do to help.