Access/ibility: Access and Usability for Digital Publishing
Best Practices for Creating Accessible Digital Texts
The following document aims to address the full range of barriers to access and suggest best practices for working toward the goal of full access/ibility for digital publications. As with all of the documents in this collection, we welcome suggestions for improvement, additional uses, revisions, and remixes of this content.
Before You Begin: For Creators
- Access/ibility is a rhetorical process: consider the audiences (scholarly or public) and their motivations for accessing your text.
- Start with web accessibility from the beginning of your digital project. "Incorporating accessibility from the start of a project increases the positive impact of designing for a broad constituency while decreasing development costs associated with accessibility when it is addressed much later." See http://www.w3.org/WAI/EO/wiki/Start_with_Accessibility
-
Participatory action research methodologies are one potential starting point for thinking about not only user testing, but participatory design of content and platforms.
- Kitchen, Rob. "Using Participatory Action Research Approaches in Geographical Studies of Disability: Some Reflections." Disability Studies Quarterly. 21.4: 2001. http://dsq-sds.org/article/view/318/384
- Consider the resources available to your reader (resources not limited just to device or mode of access, but also in terms of available time, for example, or social capital and networks).
- New specifications from the World Wide Web Consortium, WHATWG (Web Hypertext Application Technology Working Group), and others are released often; be prepared to embrace emerging standards if they offer substantial advantages over current methods and tools; especially if those emerging standards are based in the accessibility community.
- Consider sustainability and long-term preservation issues from the start and build them into the design.
- Consider the afforances and constraints of open standards versus proprietary or restricted standards—standards and formats that are publicly available without restriction and constraint and can be freely developed are believed to have longer-term sustainability than proprietary ones. However, a pragmatic approach will recognize that important early work on many topics is performed by vendors, so refusal to use non-open formats and systems may be too limiting when specialized applications are required.
- Navigation: Have multiple points of access or entry, redundancies in organization, sitemap, visual hierarchy.
-
Use metadata for accessibility, usability, and sustainability
- Administrative metadata provides information regarding provenance, ownership, revisions/changes, and rights management.
- Preservation metadata includes information related to the long-term preservation, sustainability, and usability of digital objects. The PREMIS Data Dictionary for Preservation Metadata is the international standard.
- Structural metadata such as METS (Metadata Encoding and Transmission Standard) and SMIL (Synchronized Multimedia Integration Language) help facilitate navigation and presentation by describing the physical and structural elements of digital objects.
- Technical metadata describes the technical attributes of a digital object related to its creation and production.
- Create structured XML / XHTML documents so that reading order and section transitions are maintained for non-visual users. Structure should follow EPUB 3 conventions, which are designed to maximize accessibility by creating consistency in the navigation of high-level elements. To quote Matt Garrish, author of Accessible EPUB 3, "HTML5 grammar, for example, solves the problem of a multitude of structural containers with only slightly differing purposes by introducing the section element." A list of preferred structural tags for EPUB sections is available at: http://www.idpf.org/epub/vocab/structure/
- New specifications from the World Wide Web Consortium, WHATWG (Web Hypertext Application Technology Working Group), and others are released often; be prepared to embrace emerging standards if they offer substantial advantages over current methods and tools; especially if those emerging standards are based in the accessibility community.
- Have clear guidelines for authors to help them produce accessible texts as well as for editors to edit texts to make them as accessible as possible.
-
Conduct user testing:
- Be sure to involve people with disabilities. Engage with Participatory action research methodologies.
- Accessibility means accessing on a range of devices, from mobile to refreshable braille. Responsive design.
-
Conduct web accessibility testing in addition to user testing. Accessibility testing allows authors to determine how well their web texts conform with the success criteria of WCAG 2.0 and legal requirements of Section 508. See http://www.w3.org/WAI/eval/Overview.html. Many tools are available for evaluating web accessibility:
- WAVE Toolbar: from WebAIM, an extension originally designed for the Firefox browser. A version for Chrome is also available. Very user-friendly, but not as customizable or as detailed as HTML_Codesniffer.
- HTML_CodeSniffer: a bookmarklet that works with almost any browser. Very detailed, customizable, but not as user-friendly as WAVE Toolbar.
- Tota11y: "an accessibility visualization toolkit...a single JavaScript file that inserts a small button in the bottom corner of your document." Click on the button and you will see where your web page has accessibility problems.
- pa11y: "a locally hosted command line tool that lets you check the accessibility of web pages, your own or others'."
- Consult also: Web Evaluation Tools List from the W3C Web Accessibility Initiative.
- Include ways for users to easily report accessibility issues with your published materials
- Prefer access methods that include browser-based options, since some readers will be on library computers or other equipment where they do not have admin rights to install software.
- Strive for cross-browser compatibility, responsivity, and graceful degradation.
- Consider that users may encounter your documents without your intended layout; make sure that your content is understandable when encountered out of context. Strive for structured presentation of text that is both human and machine-readable. Structure is a core value of accessible texts. (In this context, "structured text" refers to hierarchical tags that mandate a specific reading order, not to the computer programming language by the same name.) Structured XML / XHTML documents maintain reading order and section transitions for non-visual users. Structure should follow EPUB 3 conventions, which are designed to maximize accessibility by creating consistency in the navigation of high-level elements. According to Matt Garrish, ""When you make up your own structures using generic tags, you push the logical navigation and comprehension of those custom structures onto the reader (and potentially mess up the HTML5 outline used for navigation). Sighted readers may not notice anything, but when reading flows through the markup, convoluted structures can frustrate the reader and interfere with their ability to effectively follow the narrative flow." See http://idpf.org/forums/epub-accessibility
- Navigability is also a core value of accessibility (and requires structured content).
- Consider use of color. If color were removed, would it inhibit use? Is color anywhere used to draw attention or offer meaning that would be lost if reader could not see? (Be aware of grayscale devices.) Test color contrast to ensure readability:
- Consider overall 'flow' of design elements and potential for distraction.
- Tag elements appropriately for ease of navigation (consider navigation without a mouse or trackpad, navigation via screen readers, etc.). Follow current EPUB3/HTML5 best practices for semantic element names.
- Users should be able to interact with your resource using keyboard alone (without the use of a mouse or trackpad). See http://webaim.org/techniques/keyboard/
- If the reader is asked to submit any kind of feedback or to interact with the text, be sure to include feedback mechanisms, such as confirmation of response, indication of progress toward completion, time left to complete or timeout, etc.
- Anticipate that some users will want to view your web text with their own style sheets. See http://webaim.org/techniques/css/
- Avoid "click here" links. All links should make sense in context (be rhetorical; emphasize the purpose of the link).
- Avoid using images of text on the web because some people will find them hard, if not impossible, to read.
- http://www.4syllables.com.au/2011/06/accessibility-web-writers-part-7/
- http://webaim.org/techniques/images/#enlarging
- If using Adobe PDF, make sure it is accessible with tags and correctly marked-up reading order (see http://webaim.org/techniques/acrobat/) Distinguish between 1. PDFs that contain scanned images of born-printed documents (often with rough OCR as machine-readable text underneath the image), and 2. born-digital PDFs where the text that is visible is the machine-readable text. The former are not accessible in that the error rate on uncorrected OCRed text is too high for a screen reader to be able to read the text aloud and have it sound like something other than nonsense. PDFs from OCR workflows are also likely to lack proper structure (what appears to be two columns of text to a sighted reader may in fact be consumed by a screen reader as a single block of text, causing unconnected sentences to become intertwined).
- Use alternative text with every image and embedded media element to provide a clear and concise textual description of the image and improve accessibility; e.g. alt attributes should describe the image, title attributes should explain the rhetorical use of the image.
- Prefer palpable content to enhance/describe image and media presentation. That is, use tags like <figure>/<figcaption> that place content readily accessible to all users. (See the WHATWG HTML spec on "palpable content": https://developers.whatwg.org/content-models.html#content-models
- Make use of the <picture> and <source> tags along with the srcset attribute to deliver properly-sized images of the correct pixel-density; see https://responsiveimages.org
- Where possible, avoid use of moving images/GIFs with rapid refresh rate, or moving images that involve blinking, pulsing, or quick movement of dots and narrow stripes. These are potential seizure and migraine triggers. If such content is necessary or integral to the project, provide ample, emphasized warning on a splash or entry page.
- MP3 is the defacto "standard" at this time, and will likely be even more ubiquitous once the patents expire in the near future.
- Include transcripts for spoken words and other significant nonspeech sounds: cf. http://webaim.org/techniques/captions/#transcripts
- Current best practice is to use H.264 or WebM video formats, delivered via HTML5 (which allows for subtitles, captions, and time-synchronized events). WebM produces smaller files but is less widely supported.
- Include audio descriptions: http://webaim.org/techniques/captions/#ad
- Include captions & subtitles: http://webaim.org/techniques/captions/#captions
- If using proprietary presentation software (e.g., Flash, Quicktime, .wav, PDFs, etc.), provide alternate versions of your text as XML and/or transcripts to increase readability and accessibility of your webtext.
- Avoid delivery of content via Flash; it's proprietary, not easily supported and constantly requires updates from the user (a potential problem for some users).
- Where possible, avoid use of video with rapid refresh rate, or moving images that involve blinking, pulsing, or quick movement of dots and narrow stripes. These are potential seizure and migraine triggers. If such content is necessary or integral to the project, provide ample, emphasized warning on a splash or entry page, or in the opening slides/credits of the video clip. For more info on flicker thresholds, see: http://webaim.org/articles/seizure/
- Accessibility statement generator: http://www.accessibilitystatementgenerator.com/
- Sustainability of Digital Formats: Planning for Library of Congress Collections: http://www.digitalpreservation.gov/formats/
- Designing for (and with) colorblindness: https://medium.com/@aaron10buuren/designing-for-and-with-color-blindness-48392aab3d
- Web Accessibility Center at Ohio State : http://wac.osu.edu/
- WebAIM.org is a complete and authoritative resource for web authors on making webtexts accessible. Every year, they conduct a screen reader survey. http://webaim.org/projects/screenreadersurvey/
- The Described and Captioned Media Program's The Captioning Key is a set of guidelines for adding closed captions to web video: https://www.dcmp.org/captioningkey/
- Web Content Accessibility Guidelines (WCAG) 2.0: http://www.w3.org/TR/WCAG20/
- EPUB3 Accessibility Guidelines: http://www.idpf.org/accessibility/guidelines/
- IDPF discusion forum on EPUB3 accesibility: http://idpf.org/forums/epub-accessibility
- Specifications for EDUPUB, a profile for creating accessible EPUBs intended for academic settings: http://www.idpf.org/epub/profiles/edu/10/
Links for Further Reading on Accessibility
- Star Ford on Deep Accessibility: https://ianology.wordpress.com/2013/09/06/deep-accessibility/
- Ari Ne'eman, Making Disability Studies More Accessible (article content goes beyond DS to academia more generally): http://autisticadvocacy.org/2012/05/making-disability-studies-accessible/
- HASTAC, Moving Beyond Access in the Academy: http://www.hastac.org/forums/disability-moving-beyond-access-academy
- Advisory Commission on Accessible Instructional Materials in Postsecondary Education for Students with Disabilities, US Department of Education: http://www2.ed.gov/about/bdscomm/list/aim/resources.html
- Quesenbery and Horton's A Web For Everyone (Rosenfeld Media, 2014) offers a fantastic overview that puts a more accessible wrapper around the often dense WCAG 2.0 standards. http://rosenfeldmedia.com/books/a-web-for-everyone/>