TL;DL – .NET Rocks! 1369 (Web Accessibility with Aaron Gustafson)

Show link: .NET Rocks! 1369: Web Accessibility with Aaron Gustafson

Guest: Aaron Gustafson

Show Notes

  • What is progressive enhancement?
    • Think about the core experience, content, or task for your site, and be able to provide that regardless of the browser, device, or connection. It’s about embracing the experience from the most basic to the most high fidelity (i.e., richer in a different context).
    • Example: Capturing an e-mail address in a form. input type=email gets support in browsers, virtual keyboards with the @ symbol more prominent, browser validation, etc., which is better than just a free-form text field. (Note: If the browser doesn’t support that input type, it falls back to text.)
  • Doesn’t adaptive design apply to downlevel browsers?
    • Traditionally, yes. Progressive enhancement is a specific type of graceful degradation; you take the basic interface and then improve it.
    • We’re thinking about future improvements rather than compensating for older browsers.
  • What about sites that say you need a modern browser?
    • That says there’s a single experience, which ignores the reality of the Web.
    • As developers, we don’t control the execution environment (e.g., browsers, plugins, configurations, networks) of our code.
    • Example: In 2011 Gawker Media launched a web platform where JavaScript was used for all content loading. There was a bug in the JavaScript such that no sites ran.
    • Example: Sky Broadband (UK) misclassified jQuery served from the jQuery CDN as malware; with no local fallback, your page won’t render.
  • Are you a hamburger menu guy?
    • It depends; every site has its own unique needs. At least say “menu” or “navigation.” Assistive technology may not tell the user what functionality the hamburger menu provides, so you’re creating an impedance.
  • What percentage of web users require some kind of accessibility help?
    • There isn’t much data here, as there’s no way within standard web stack (HTML/CSS/JavaScript) of detecting such technology. Anecdotally, a “surprising” number of people use high-contrast mode in Windows.
    • Most people gravitate towards people who use screen readers when thinking about accessibility.
    • Accessibility is a broad spectrum. Examples of mousing with your non-dominant hand, needing larger hit targets
      • Few — permanent loss of a limb
      • Somewhat larger — temporary disability (e.g., broken arm)
      • Many — situational (e.g., new parent holding a newborn in one arm)
  • Curb cuts were required for ADA compliance in the US to enable people in wheelchairs to cross the street, but we all benefit from them (e.g., strollers, bikes, package dollies).
  • Low contrast is an issue for many reasons — e.g., users with vision problems, mobile device users who turn down the brightness to conserve battery, users viewing a device in the sunlight with glare.
  • Good semantic HTML markup helps those using screen readers and those using services such as Siri, Alexa, and Cortana.
  • What’s the difference between adaptive vs. responsive web design?
    • There’s inconsistency in the industry about what those terms mean.
    • Responsive design (see article by Ethan Marcotte) involves fluid grids with flexible images and media queries; it fits in with progressive enhancement for the layout of the page.
  • There are several devices available in the Chattanooga Open Device Lab.
    • Barnes & Noble Nook: It’s an Android-based e-reader with a WebKit browser, five font sizes, multiple zoom levels, and portrait/landscape modes, which leads to about 30 different ways to render a page. It’s a good device for making you think about scalable fonts and flexible layouts (e.g., using em-unit based layouts).
    • Opera Mini browser: can be “hostile” (e.g., only a subset of CSS support, limitations on JavaScript support).
    • Kindle 3: has E ink transitions and Whisperet (global 3G access)
  • Are there any hard and fast rules for making your site friendly to color blind viewers?
    • Contrast is important. There are desktop apps and plugins for browsers that simulate colorblindness. You can also simply view things in grayscale.
    • Don’t rely solely on color to draw attention; use iconography (e.g., the Borland buttons).
    • Use patterns instead of just colors for graphs.
  • Are there accessibility issues around shape differentiation (e.g., play vs. stop icons)?
    • It depends on the size of the icons. Squint your eyes to see if you can still discern the difference. There are also browser tools to apply blur effects.
  • Are you ever asked to rate/score a website?
    • Not often; most of the work centers around “can you tell us what we’re doing well” and “what can we fix.”
    • You can also go too far in trying to create exact parity between two experiences.
  • Do you have any critiques of Facebook in terms of accessibility?
    • The page is very noisy. The mobile-first version aligns best with progressive enhancement: a core experience that’s very streamlined. They provide enhancements as you have more screen real estate.
  • The ARIA specification provides landmarks and roles for portions of the page that are acting as particular things (e.g., banner, navigation, main content) based on the markup. The more semantic richness we provide to our documents, the more useful they become in a wider variety of scenarios (e.g., assistive technology, web crawlers).
  • The Web Accessibility Evaluation Tool List is quite large.
    • If you’re just getting started with accessibility, there are a number of tools to integrate with Gulp/Grunt to scan your HTML for potential issues and catch the low-hanging fruit.
  • Tips: use alt text; consider the order of your content as it affects how it’s read; make a print stylesheet.
  • We need a combination of OS/browser support and semantic markup to get a better experience.
  • For developers interested in getting more granular, the Edge Developer Tools let you view the accessibility tree so you can see how the elements are being exposed to assistive technology.
  • The cost of adding accessibility on at the end is analogous to adding security and testability: It’s cheaper to do it early on.
  • Tip: Always have a keyboard shortcut for actions on the page, or at least make it keyboard focusable by setting tabindex=0.

Better Know a Framework

Listener E-mail

From show #761 (accessible web applications); unless accessibility is mandated or required by law, very few companies will do it. There should be tooling or OS support to make things more accessible (e.g., color correction at the OS level for colorblindness); have the tooling vendors help with this instead of relying on individual developers who may not know of or understand accessibility issues.

Technology Giveaway Ideas