Along with nearly every other industry, the world of higher education is facing unprecedented transformation driven by evolving technology. While developments in technology can present challenges, they also offer solutions. Schools participating in federal financial aid programs are required to make reasonable accommodations to ensure their websites and web-based content are accessible to the broader population, including differently-abled people. Meeting these requirements can feel like a daunting and complex subject. What’s involved in improving accessibility? Where’s a good place to start? How does an institution measure progress? What does “good” look like? In this webinar, we will cover: - An overview of accessibility and key areas of importance - Options for addressing accessibility requirements - How to plan an accessibility projectA live demo of the free OpenEDU accessibility checker for Drupal 8

1. Improving Accessibility for
Higher Education
June 12, 2019

2. Speakers
Jeff Reed
Sr. Solutions Manager
Acquia
Bjorn Thomson
Sr. Digital Experience Architect
ImageX
Renée Stephen
Technical Solutions Manager PS
Acquia

3. What’s coming up?
● An overview of accessibility and key areas of importance
● Options for addressing accessibility requirements
● How to plan an accessibility project
● A live demo of the OpenEDU accessibility checker for
Drupal 8
● Q & A

4. What is accessibility and
why does it matter?

5. Key areas of importance
Accessibility considerations for:
● Designers
● Developers
● Content editors

6. Accessibility for Designers
● Contrast and size
○ How to check
● Avoiding using color alone to indicate
meaning
○ I.e., error messages, hover states
● Supporting keyboard navigation
○ Placing items in logical order
○ Making content, interface concise
● Making content discoverable
○ Clear labelling, avoiding ‘learn more’
● Clearly indicating focus
● Ensuring forms are logical and easy to use

7. Accessibility for Designers
● Auditing brand colors:
○ Identifying “core” compliant
colors
○ Determine if any need to be
slightly tweaked (i.e.,
darkened) to achieve
compliance
○ Can use lower-contrast colors
as accents, visual motifs

8. Accessibility for Designers

9. Accessibility for Designers
● Tools you can use:
○ WebAIM contrast checker
○ Stark plugin for Sketch
○ Color Oracle
https://www.getstark.co/adobexd/index.html

10. Accessibility for Designers
● Tools you can use:
○ WebAIM contrast checker
○ Stark plugin for Sketch
○ Color Oracle
http://colororacle.org/

11. Accessibility for Developers
● Using semantic markup
● Supplementing semantic markup with
ARIA
● Ensuring logical DOM order
● Form building for accessibility
● Helping users avoid mistakes, being
forgiving and helpful with errors
● Considerations for screen readers

12. Accessibility for Developers
Semantic markup
ARIA attributes to supplement semantic markup
<main><h1>Hello</h1>
<section><h2>About this document</h2>
<content>...</content>
</section> ...
</main>
<main>
<ul>
<li tabindex="0" class="checkbox" role="checkbox" checked aria-checked="true">Buy
now</li>
</ul>
</main>
Example adapted from https://developers.google.com/web/fundamentals/accessibility/semantics-aria/

13. Accessibility for Content Editors
Considerations for Content Editors:
● Clear, concise copy
○ Navigating when disabled takes
extra time; make it easier and faster
for them -- and everyone
● Links in context - no "click here"
● Including alternative text
○ I.e., image ‘alt’ text
○ CMSs like Drupal help with this
● Use actual headings
○ Use headings for structure, not
emphasis
● Providing captions for video and
transcripts for audio

14. What are your options?

15. Identifying target compliance state
● About WCAG levels A, AA, AAA
○ Implications of setting each as a goal
○ About 2.0 vs 2.1 standard
● In some cases, the compliance level may be mandated
● In cases where it is not mandated, level AA is commonly defined as the goal

16. Assessing current state
● Manual vs automated testing
○ Not all testing can be automated
● Tools you can use to automate testing
○ WAVE
○ SiteImprove
○ Lighthouse
○ OpenEDU Drupal 8 checker
● Selecting automation tools
○ Cost vs. time
○ Skills required
○ Combining tools
● Beyond automation: manual testing
○ Which types of testing require manual work
○ Manually testing in-house vs outsourcing

17. Example tool: Lighthouse
● Part of Google Chrome developer
tools
● Allows users to:
○ run an initial audit of a page,
get score
○ inspect and modify the
elements that did not pass to
quickly resolve issues
○ see a list of ‘next steps’
including manual testing steps

18. Example tool: Lighthouse
● Part of Google Chrome developer
tools
● Allows users to:
○ run an initial audit of a page,
get score
○ inspect and modify the
elements that did not pass to
quickly resolve issues
○ see a list of ‘next steps’
including manual testing steps

19. Example tool: Lighthouse
● Part of Google Chrome developer
tools
● Allows users to:
○ run an initial audit of a page,
get score
○ inspect and modify the
elements that did not pass to
quickly resolve issues
○ see a list of ‘next steps’
including manual testing steps

20. Example tool: Lighthouse
● Part of Google Chrome developer
tools
● Allows users to:
○ run an initial audit of a page,
get score
○ inspect and modify the
elements that did not pass to
quickly resolve issues
○ see a list of ‘next steps’
including manual testing steps

21. Example tool: Lighthouse
● Part of Google Chrome developer
tools
● Allows users to:
○ run an initial audit of a page,
get score
○ inspect and modify the
elements that did not pass to
quickly resolve issues
○ see a list of ‘next steps’
including manual testing steps

22. Example tool: Lighthouse
● Part of Google Chrome developer
tools
● Allows users to:
○ run an initial audit of a page,
get score
○ inspect and modify the
elements that did not pass to
quickly resolve issues
○ see a list of ‘next steps’
including manual testing steps

23. Example tool: Lighthouse
● Part of Google Chrome developer
tools
● Allows users to:
○ run an initial audit of a page,
get score
○ inspect and modify the
elements that did not pass to
quickly resolve issues
○ see a list of ‘next steps’
including manual testing steps

24. How to plan for your accessibility project
● Different types of accessibility projects
● Overall structure of an accessibility project

25. Types of accessibility projects
● Projects from scratch
○ Setting design team up for success
○ Structuring development process for accessibility
○ Accessibility testing (usability testing, QA)
○ Training content editors and creating awareness/documentation during
project and after launch
○ Setting ‘checkpoints’ after launch
● “Repair” / audit projects
○ Assessing initial state
○ Identifying issues and priority
○ Identifying skills and resources needed
○ Planning project

26. Structuring an accessibility project
● Project planning
○ Identifying goals and current state
○ Identifying skills required
○ Budget and timing
○ Where you may want / need to
outsource
● Project structure
○ Initial discovery
○ Identifying, prioritizing and
estimating issues
○ Assessing progress

27. Project Case Study: Open Y Audit and Improvements
● About the Open Y project
● Planning the project
○ Project goals
○ Structure of team and activities
■ Initial audit
■ Tracking and reporting bugs
■ Estimation
■ Project management flow and tools
○ Team personnel and skills
○ Automated and manual testing
■ What was in-house vs outsourced
○ Project outcomes: successes and
lessons learned

28. Project Case Study: Open Y Audit and Improvements
How we tracked issues:

29. OpenEDU Demo

30. Additional Resources
● https://www.accessibility-developer-guide.com/knowledge/
● https://www.w3.org/WAI/tips/developing/
● https://www.washington.edu/accessibility/checklist/
● https://medium.com/salesforce-ux/7-things-every-designer-needs-to-know-about-acce
ssibility-64f105f0881b
● https://uxdesign.cc/designing-for-accessibility-is-not-that-hard-c04cc4779d94
● https://webaim.org/resources/contrastchecker/
● https://zapier.com/blog/accessible-web-content/
● https://developers.google.com/web/fundamentals/accessibility/semantics-aria/
● https://www.w3.org/WAI/fundamentals/accessibility-usability-inclusion/
● https://www.w3.org/WAI/test-evaluate/combined-expertise/

31. Questions?
Jeff Reed
Sr. Solutions Manager
Acquia
Bjorn Thomson
Sr. Digital Experience Architect
ImageX
Renée Stephen
Technical Solutions Manager PS
Acquia