- What is in the toolbox already: Demos
- Sprint design challenges
- Adrian Garcia's thoughts on Authoring accessible links
Choosing Challenges to Work OnAfter coming up with design challenges, we voted on the ones we would start to work on. We discussed voting criteria including the importance of the problem and the tractability of prototyping a solution in a short time. We voted with colored sticky notes and I tallied the top three vote getters. We chose three so that we could have two design teams for each problem and compare the results. The top three vote getters were ...
- Idiot proofing the authoring process for accessibility
- Making annotation accessible
- Supporting a STEM scholar that wants to submit articles that are also accessible.
Idiot proofing the authoring process for accessibility
- Have a description bank for images.
- Create table of contents automatically so screen readers have good navigation and so that authors see a representation of the structure of their content which might encourage better structure.
- Make footnotes smart and easy to create. (I didn't fully catch this one, but I think the suggestion is to make footnotes easily to create in ways that link them to the content they are footnoting so that screen readers can find them in context).
- Have smart defaults. Include header rows by default in tables and suggest authors use headings.
- Mimic Wordpress' image insertion which shows you caption, alt text, and description in a side panel. These create good habits and expectations in authors.
- Have a preview mode that reads your content back to you so you can experience what someone listening to it experiences.
- Have an "accessibility check" mode like spellchecking.
- If images are described, make sure to add that to the metadata for discoverability of the resource.
Making annotation accessibleThe two design teams took two very different angles at this problem. One team brainstormed ways to use annotations as a new way to crowd source descriptions of images and alternatives for inaccessible content. The other looked specifically at Hypothes.is' interface, to figure out how to make reading annotations and creating annotations accessible. In order to crowd source annotations, that team envisioned a specific annotation layer for accessibility, with a user interface (UI) specialized for adding accessibility information. The UI would have drop downs for images, graphs, math, etc. Readers would flag resources as inaccessible and request descriptions or alternatives. Responders would have templates for the accessibility information requested. Finally, there would be a way to vote on the best descriptions and/or alternatives. The team looking at making Hypothes.is accessible for authors found that it needed a keyboard shortcut for adding annotations. Additionally, so that readers know when an annotation is present, the team envisioned a configurable tone that would indicated the presence of annotations.
Accessible Scholarly Authoring
The next post will include the results of prototypes created the next day.