Skip to content
Permalink
master
Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

typography/accessibility.md

Go to file
 
 
Cannot retrieve contributors at this time
Midterm Project Accessibility settings Location within the app Low vision concerns and impared mobility Accessibility context while designing Conclusion
53 lines (33 sloc) 5.49 KB
Raw Blame
Open in GitHub Desktop
  • Gideon Slife
  • DMD 5998 - Design for Accessibility & Inclusion
  • Oct 16, 2021

Midterm Project

As my thesis project is on the web, this paper will focus on identifying areas where accessibility could be improved.

Accessibility settings

While the design of the application is very important as it relates to the content, a user should be able to override certain parts of the design if needed. A tab dedicated to accessibility settings would be very helpful so users can change aspects of the design. This tab should allow the user to change: font style, font size, enable a high contrast mode, and print the lesson.

The a serif typeface is currently used, but a user would be able to change this to Lato (a sans-serif) or to OpenDyslexic, a typeface designed to be more legible for users with dyslexia. When OpenDyslexic is selected as a typeface, word spacing will also be increased, as large word spacing improves legibility for dyslexic people. The font size can also be overriden, except in acitvity areas where the user already controls the type size.

For users with low vision, a high-contrast mode can be enabled. While most of the application is already at a high contrast, this will ensure that all type falls into the WCAG AAA level for contrast ratio — 7:1.

A user will also be able to print the lesson, which will use a print style to remove any interactive elements. This doubles as users with low mobility or learning disabilities can see all the content at once and not need to use the interactive "click through" progression within the lesson if they find that a challenge. Users can save the page as a PDF or print it out.

Location within the app

A feature should be added to indicates to users:

  1. Where they are within the lesson
  2. Where they are within the application

#1 is a higher priority. It's both helpful for users with and without learning disabilities to know what percentage of the way they are through each section (roughly) and how much more content remains within the lesson. An indication similar to a video play bar would be helpful, as users could also return to a previous section. This may require ultimately exposing more of the "sectioning" of the lesson than is currently done in the design, but may help users to "chunk" the content. The lessons have intentionally been built during the curriculum design phase to be comprised of 4 or 5 sections. (See George Miller's famous psychological paper on human capacity for information processing.)

This location feature should be built as an overlay modal that the user can access at any time. This will ensure the feature remains usable at any point and can act as a reference or escape route if needed.

Low vision concerns and impared mobility

As noted above, font style, size, and high contrast mode should be added to help users with vision disabilites. Also, there are a few instances of interactive areas that need taborder set properly—particularly the progression arrows and buttons. Right now, the arrows are only clickable (though they have text visible only to by screen readers).

The following elements should also have taborder and focus styles added:

  • Range sliders
  • Carousel buttons
  • Interactive card games
  • Checkboxes

Card games need to have focus events and styles added so they can be effectively used for users with a screen reader. This will be helpful for low vision users, but also for users with impared mobility, as a mouse won't be needed to play the game.

The carousel should be checked against a screenreader to see if aria labels could improve clarity. The SVG as the graphic for the carousel is not very accessible, as it's just a map, but the text does describe the slide. Using aria-describedby is likely the best way to accomplish this.

Currently, tooltips have both focus styles and ARIA descriptions, so are fully accessible.

Accessibility context while designing

This application has been designed with accessibility in mind. While there are certainly areas for improvement, the application uses native HTML5 elements. This means that screenreaders will be able to see most of the application, and only a few hints will need to be added to clarify content. All elements will also scale if changed through the browser UI. All interactive elements adhere to WCAG AAA touch target standards of 44px, unless they're in a paragraph.

Alt text is used with any photo, or the <figure> and <figcaption> elements are used.

The app uses the standard vertical scroll so users will not need to learn a new interaction method to progress.

Conclusion

There are two major aspects of the project that will help with clarity and navigation for users: the accessibility settings and the location feature. However, the other needed features, like taborder and aria will make the individual lessons possible for low-vision or mobility-impared users. Both types of changes are needed.

It's also worth nothing that some content is impossible to make accessible for completely blind users. For example, the lesson on leading requires users to use a range slider to adjust leading to a visually legible setting. This could theoretically be done using accessible tools to progress, but the meaning of the lesson will be lost without the use of vision, much as a lesson on color theory would be inherently inaccessible.