Skip to content

Instantly share code, notes, and snippets.

@coreybruyere

coreybruyere/conference-accessibility-bay-notes.md

Last active October 29, 2016 23:18
Show Gist options
  • Save coreybruyere/6c49ce79091ba7050d9150b0ad6fc0f6 to your computer and use it in GitHub Desktop.
Save coreybruyere/6c49ce79091ba7050d9150b0ad6fc0f6 to your computer and use it in GitHub Desktop.
Download ZIP
Focusing on users with different disabilities, sessions can cover digital accessibility topics from the web (technical to tactical), desktop software, mobile apps, eLearning, online gaming, open source innovations, and everything in between. Take a look at the 2015 schedule to get a feel for the types of topics that were covered at last year's c…
Raw
conference-accessibility-bay-notes.md

Accessibility Camp Bay

[WIP] - Still cleaning up notes.

10/29/16

http://www.accessibilitycampbay.org/

An Intro to ARIA (Accessible Rich Internet Applications)

Dennis Lembree - deque

In today’s modern web, it’s essential for developers to understand ARIA. This session explains what ARIA is, why it’s important to users of assistive technology, and proper coding techniques for using (or not using) ARIA. Examples are explored with a screen reader and code inspector. Keyboard interaction patterns are also explained.

Introducing ARIA

  • Web Accessibility Initiative has examples, guidelines, and techniques.
  • ARIA fills gap between assistive technology and code.
  • HTML attributes that start with aria- or role.
  • Doesn't change any visuals.
  • Roles = button, header, main.
  • States and Properties = aria-checked.

Ground rules

  • ARIA changes HTML semantics. Always overrides it.
  • ARIA doesn't solve all problems.
  • If in doubt, leave it out. Focus on proper HTML semantics and keyboard interaction.
  • Use progressive enhancement.
  • Add ARIA last.
  • Use caution with role=form, role=application, and drag-and-drop.
  • Don't use tabindex=0 or tabindex=1 unless you know what you're doing.
  • Never use tabindex=1+.

Keyboard interaction

  • Users physically unable to use a mouse will use assistive technologies.
  • Tab, Enter, Spacebar, and arrow keys are primary keyboard input keys.

Examples

  • aria-live=off|polite|assertive
  • aria-atomic
  • Demos

Tools and Demo

Accessibility Testing Tools for Developers

Gerard Cohen - Lead Accessibility Strategist

You don't have to be an accessibility expert to make your projects accessible, but you do have to make your projects accessible.

Identifying accessibility issues as early as possible can save an organization or project a substantial amount of money, time, and headaches over trying to augment a web site or application after initial development. Using testing tools during development for accessibility will definitely help with this process.

For developers that are novice to web accessibility this presentation is a great introduction into key aspects to consider while developing. For developers that are more familiar, this presentation exposes tools that will make accessibility easier. All users will gain from learning how to build accessibility into their development workflow using a variety of testing tools, from simple to intricate.

Accessibility Testing

  • Test early and test often
  • Deferring accessibility towards the end is expensive.
  • Validate HTML.
  • Web Developer Tools Extension.
  • Keyboard Focus with tab.
  • document.activeElement to find focused element when debugging.

CSS Bookmarklets

JS Bookmarklets

Accessibility Tools

Advanced Testing

When To Test?

  • Test on save.
  • Test before commit.
  • Test on CI.

Conclustion

  • Nothing replaces manual testing.
  • Use assistive technology before setting up automated testing.
  • "How to Meet Web Performance Guidelines - Plurasight Course".

Getting Started with Accessibility Testing

Kimberly Munoz - something

This talk will cover keyboard accessibility testing for beginners, as well as considerations for text-heavy sites accessible using headings and landmarks.

Basic Testing

  • Use aXe-core or tota11y to find problems with contrast, alt text, missing labels, bad link descriptions, etc. (See link list from previous presentations).
  • Test for keyboard accessibility.
  • Better keyboard accessibility helps all users, not just disabled.
  • Web Accessibility Perspectives
  • Can you navigate to everything using a keyboard?
  • Can you skip repetitive links and tabbing?
  • Can you see when you're navigating?
  • Can you get your keyboard focus "stuck" ("keyboard traps").
  • Use TAB to move forward and SHIFT + TAB to move back.
  • ENTER used to select buttons and links.
  • SPACEBAR used to select items like dropdowns, buttons, and checkboxes.
  • ARROWS scroll through dropdowns, radio buttons, sliders, autocompletes.
  • Can you tab out of a modal without exiting?
  • Can you trap your keyboard focus unintentionally and never get out?
  • Don't {outline: none} anywhere!
  • Don't mess with tabindex and sort items in proper order in the DOM.
  • Use semantic HTML - Elements have ARIA baked into it. e.g., <button>.
  • WAI-ARIA Authoring Practices - keyboard interaction examples.

Optimize Content

  • 65% of screenreader users use headings to navigate lengthy webpages.
  • VO + U to activate Voiceover rotor and see headings.
  • tota11y has tool to test headings.
  • Use one h1 for page title.
  • Do not skip heading levels.
  • Be descriptive with headings.
  • Have headings reflect an accurage page outline.
  • Only use 7 landmarks per a page.
  • Don't overuse <section>.

Pragmatic Accessibility Testing in CI with AccessLint

Cameron Cundiff - thoughtbot

AccessLint CI is a pragmatic, developer-centric way to test web accessibility. It offers fixes and guidance on issues in near real-time, without "stopping the presses" with a failed build.

The session will look at why we built AccessLint CI, how it works, and some examples. It's especially geared towards developers who want free, robust, nonintrusive accessibility build tools.

AccessLint

  • Suite of accessibility tools.
  • Open sourced on GitHub.
  • Web-based, Developer-centric GitHub Workflows, Continuous Integration.
  • Ruby-based.
  • Bot based tool that doesn't fail during build.
  • Production analytics.
  • Only available on Circle CI.
  • Once logs are stored in S3 service will be agnostic and available on other CI's.

Accessibility at the Intersection of Visual Design and Front-End Development

Mitchell Evan - SSB Bart Group

Some accessibility problems seem hard because of unclear expectations. Who is responsible for the keyboard experience? When is the right time to fix a UI widget library? Why is it hard to fix a color palette? We'll review technical solutions for common accessibility challenges, and identify how these solutions fit in the workflows for project teams.

Accessibility Maturity

  • Accessibility starts with a compliance event, discovery, remediation, and standardization.

Plan for Color Contrast

  • Designer is mainly responsible for accessible design.
  • Choose a testing methodology and tool.
  • Make a solid plan to fix early in a design cycle.
  • Always ask who is excluded from a design.

Keyboard Access

  • Tab order, focus management for in-page updates, focus, keystrokes to select or activate.
  • All UI devs should know how to to these with a sighted keyboard:
    • TAB and SHIFT + TAB.
    • ARROW or SPACE to select.
    • ENTER or SPACE to activate.
    • Visual focus indication on all tabbable elements.
    • Logical focus location at all times.

What's Next?

  • The gap between designer and developer is closing in.
  • Teams should be aware of everyones role.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment