accessibility

Project: Make a large application accessible and create a workplace culture of accessibility.

Description: Excerpt from blog post I wrote that's essentially a mini white paper about how we made a large healthcare application accessible. Here I worked closely with a product manager and our UX manager to make our application accessible according to the Web Content Accessibility Guidelines (WCAG), writing business requirements based on the WCAG and conducting testing.

Project: Internal memo

Description: Accessibility project update for management team (internal communication). The goal for this project was to get management buy-in to the project.

Accessibility recommendations/overview

There are a number of challenges and opportunities involved in improving our accessibility.

Small Changes, Big Impact

There are small changes we could make to our UI right away that would have impact. Some

examples:

• Change the language on buttons and in links to be more explicit

• Explain when a link will go to a third-party site before the link is clicked

• Remove language like “heading 5” “chevron” and “image” from the application

• Publish a page of accessibility tips for people in the application

• Publish a company accessibility policy in the application and on our website

More Effort, More Impact

Some changes would take more effort but still feel within reach. Here are a few examples of changes we might make:

• Adding headings throughout the screens to help with logically organizing the content

• Changing the web content to be recognizable by screen readers

• Conducting usability testing and QA for all devices using screen readers

• Creating new alt text (and standards for these) for images and graphics

• In some cases, hiding the alt text, icons, images and graphics

• Making sure screen readers can distinguish between buttons and links

• Creating links that stand out; testing text and background color combinations for people with color blindness.

• Using a skip navigation link to allow people to jump to the main content

• Tag content inside of pdfs to make sure screen readers can correctly read the content.

• Fit and Finish issues. For example, audit all the input fields (checkboxes, radio buttons, input fields, labels, input with buttons, buttons) and make sure they are using the correct bootstrap markup and have the correct margin/padding. Fix alignment and height of various elements and more (clean the stove).

Big Changes, Biggest Impact

There are larger changes we could also make that would have even more impact that would represent a shift in the way the application is designed and very significant changes to the UI. Examples include:

• People can search for doctors, hospitals and costs using keyboard clicks

• All content, forms, etc. are available by tabbing or using the arrows or both

• Screen readers can read web content

• Web content works well with screen reader functions (ex: ctrl + opt + space)

• New formatting and standards for form controls, headings, links and web spots so our screens are compatible with screen reader rotors (they summarize screen info)

• Add ARIA landmarks so people can jump to an area of a screen with a keystroke.

• Organizing screen layouts to have a left to right tabbing order (an “F” pattern)

• Evaluate how well the location field, plan field and category search (the dropdown menu system) work with screen readers and making changes to prevent users from becoming “stuck” in these fields.

• Reviewing the use of Compare and dynamic content like interrupts, modals, popovers and tooltips in the application and in some cases, coming up with different solutions for these designs and the content.

• Review the use of tabbed content (ex: rewards) and in some cases, coming up with different solutions for these designs and the content.

• Review the use of data in the application and determine if new standards are needed for this content to be available to screen readers.

• Summarizing large sections and offering a way to skip past these sections when using a screen reader. Filters, and each item being filtered, is a formidable number of items when you are tabbing through each one.

• Using a list format for lists would make them easier to parse.

• Add a text-only version of the application that people can turn on or off (if it can be kept updated).

• Adding captions or transcripts for videos on healthsparq.com (Marketing).

• There is often jargon and legalese and content that wasn’t written with active verbs or written at an 8^th grade reading level added to the application.

To be more inclusive, we could standardize various elements in the application to make it easier for screen readers to parse them. We could also publish a page in our application with tips for using the application with a screen reader.

Things We’re Doing Well

While we look at things to change, we should also look at some things we are doing well:

• Using responsive design so pages automatically resize for tablets and mobile devices.

• Although sporadically, we have on some screens utilized button and link text very well, using very clear and distinct directives (on other screens they need updating).

• The Content team writes content using active verbs and short, simple sentences that are easy to understand (8th grade reading level).

• Using color with care, where most of the cues to people are in other forms (buttons, links, asterisks).

• Generally, we do a good job with naming form fields.

Project Global Accessibility Awareness Day presentation

Description: Excerpt from Global Accessibility Awareness Day presentation (internal communication). This was part of a larger effort to make our application accessible. The goal for this project was to create a culture of accessibility and to engage subject matter experts who needed to be on board for project to succeed.

• Millions of people are denied full access to the web because of how sites and applications are built.

• Web interactions rely on assumptions, which lead to inaccessible content.

• Accessible design also benefits older users, people who are injured and users in rural areas.

• Roughly 48 million people, 20% of Americans, are deaf or hard of hearing.

• 10% of adult Americans over 18 have some degree of vision loss. That's 23.7 million people.

• The following guidelines are for users in these areas:

  • • Low vision

    • Deaf and hard of hearing

    • Dyslexia

    • Motor disabilities

    • Users on the autistic spectrum

    • Users of screen readers

Project Talking points for account managers and business analysts

Description: These training materials were created to help customer-facing employees (B2B) explain accessibility efforts to clients.

Accessibility Checklist for AMs/BAs

This checklist was created to help you guide clients in maintaining an accessible experience for users. This list is not meant to be comprehensive. Please check with the compliance officer if you have questions.

Alerts

See “images,” “links” and “plain language” sections.

Content tiles (member cards)

See “links” and “plain language” sections.

Color

There should be a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text, and a contrast ratio of at least 3:1 for graphics and user interface components (such as form input borders). Use the online color contrast checker to verify.

Also, don’t use color as the only way to present information.

Error messages

If a client is creating new error messages they need to suggest fixes (what the user can do next). Users need a means of escape from an error message; make sure users can’t get “stuck” on an error message. See also “plain language.”

Images

Images or icons cannot be used for content if there is no other content representing the same information. The visual image cannot be the main means of conveying the information. We have to add alt-text if the client doesn’t supply it.

Do not use images of text.

Links

Use explicit descriptions in link text: “Sign in to your account” or “Get cost estimates” are good examples of descriptive link text.

Plain language

Use plain language for text. Clients should check the readability score of custom content and use the Dale-Chall list of familiar words. Avoid unusual words. Explain abbreviations and acronyms the first time they are used.

Promo boxes

See “images,” “links” and “plain language” sections.

Scannable content

Use short sentences and paragraphs and headings and labels to make new content easy to scan.

Videos/audio

Include captions and/or transcripts with video or audio. Don’t automatically start either.

Special considerations

Make sure that configurations and custom work do not have accessibility implications.

______________________________________________________________________

Section 508 information

The law

In 1998, Congress amended the Rehabilitation Act of 1973 with Section 508. The 508 standards and guidelines require that all Federal agencies make their website content accessible to people with disabilities. Section 508 applies to any company that does business with a federal agency, including healthcare.

Section 508 talking points

• The role of differently abled users is considered in design, development and testing of the new UI.

• We want all of our new solutions to satisfy Level A and AA Success Criteria set forth in the WCAG 2.0.

• Before each major product release, Quality Assurance runs a Section 508 compliance audit on each application using a 508 compliance test template. Issues are identified, and defects are recorded for any outstanding issues. Critical and Major issues are taken care of immediately.

• For HealthSparq One, we test with screen readers, browser extensions, and an accessibility testing program (Google Accessibility Developer Tools).

• The accessibility testing we do scans our pages looking for non-compliant objects. It would not include documents that we have incorporated into a customer’s implementation (PDFs) or any pages we link out to from their implementation.