O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Improving Accessibility for Higher Education

104 visualizações

Publicada em

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

Publicada em: Tecnologia
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Improving Accessibility for Higher Education

  1. 1. Improving Accessibility for Higher Education June 12, 2019
  2. 2. Speakers Jeff Reed Sr. Solutions Manager Acquia Bjorn Thomson Sr. Digital Experience Architect ImageX Renée Stephen Technical Solutions Manager PS Acquia
  3. 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. 4. What is accessibility and why does it matter?
  5. 5. Key areas of importance Accessibility considerations for: ● Designers ● Developers ● Content editors
  6. 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. 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. 8. Accessibility for Designers
  9. 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. 10. Accessibility for Designers ● Tools you can use: ○ WebAIM contrast checker ○ Stark plugin for Sketch ○ Color Oracle http://colororacle.org/
  11. 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. 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. 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. 14. What are your options?
  15. 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. 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. 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. 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. 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. 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. 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. 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. 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. 24. How to plan for your accessibility project ● Different types of accessibility projects ● Overall structure of an accessibility project
  25. 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. 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. 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. 28. Project Case Study: Open Y Audit and Improvements How we tracked issues:
  29. 29. OpenEDU Demo
  30. 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. 31. Questions? Jeff Reed Sr. Solutions Manager Acquia Bjorn Thomson Sr. Digital Experience Architect ImageX Renée Stephen Technical Solutions Manager PS Acquia

×