Accessiblity Protototypes from the Sprint

This post points to the results of prototypes built at a sprint with educators, technologists, and accessibility specialists. Earlier posts describe the process we went through before working on prototypes.

• What is in the toolbox already: Demos  
• Sprint design challenges 
• Adrian Garcia's thoughts on Authoring accessible links
• Brainstorming solutions

After getting to know the tools we started with, describing problems that authors, readers, and learners face, and brainstorming solutions, we spent the next day organizing into small groups that would design interfaces and code prototypes to address these problems. We had people sign up in groups to work on prototypes (paper, code) that built on the brainstorming from day one. Additionally, we had lots of math and metadata experts and so groups formed to address mathematics authoring and accessibility and discovery of accessible content.

Below are links and brief descriptions of the artifacts that resulted from the prototyping:

Idiot proofing the authoring process for accessibility

• Auto-creating a Table of Contents: (oerpub's github accessibilty-sprint branch) In addition to providing good navigation for screen readers, the live TOC shows the structure of the document as it is being created, encouraging authors to see their work structurally, and hopefully improve the structure. OERPUB and FLUID worked together to get a live demo working in the oerpub editor.
• Learner controls: (oerpub's github accessibilty-sprint branch) Well structured web content can easily be controlled by learners on the fly to adjust text, color, speech options, button readability, etc. OERPUB and FLUID worked together to incorporate the FLUID Learner Options' into the OERPUB editor so that authors can see how their content looks when learners adjust those controls.
• Authoring good image descriptions (link to design and paper prototype). This team of of two started with assumptions, created user stories, built a flow chart and then made detailed UI designs for a set of wizard-like steps that help authors create good image descriptions.

Making annotation accessible

• Crowd sourcing speech for math using annotations (link to paper prototype pdf download from dropbox). The idea is to extend Hypothes.is for crowd sourcing math accessibility. It would provide a combo box with four choices - provide alternative, report issue, fix issue, or comment. Readers would rank alternatives by popularity, preference (visual, aural, braille, etc) and subject area. When reporting an issue, readers could select one of 'does not render', 'incorrect', 'confusing', or 'wrong context'. The team would like these to become github bugs using 'bugalizer' (which I think has to be created also.) To fix an issue, someone could 'choose a label', 'create an aural alternative', 'edit an aural alternative', or 'edit the equation' itself (for example, so that invisible operators could be voiced).
• Creating annotations accessibly (link to github code). Making annotations accessible will benefit readers and learnes that use voice activation, keyboard only, and switch devices. At the demo, opening the annotation side bar with keyboard shortcuts was shown, as well as getting the annotations read aloud through shortcuts. It was the first start to making annotations accessible, by using ARIA annotations and keyboard event handlers to enable opening and navigating the annotation drawer.

Better support for mathematics

• Server side mathematics rendering (link to github code, branch 'sprint'). MathJax renders mathematics in browsers on each reader's computer. However, it would be nice to have a server-side version of that also, so that content is pre-converted with the original mathematics, an svg for print and epub, and an aural representation for screen readers. They demo'd grabbing the math elements from HTML documents and handing each one to MathJax for converting to SVG and also handing to ChromeVox for generating a speech rendering.

Making accessible content discoverable 

Representatives from OERPUB, Bookshare, and Learning Registry worked together to figure out ways to make accessible content easier to find. OERPUB analyzed where metadata could be automatically generated while authoring. Bookshare is including similar fields in their description and the Learning Registry was augmented so that needs and preferences could be set before searching and then results that met or nearly met those needs could be returned.

• A11YMetadata proposal to Schema.org
• Icons for accessible content  provided by the FLUID project
• Filtering the learning registry by A11YMetadata (paper plan)