Accessibility for Everyone 読書メモ

なお、ymrl さんの文章を読み直したことが興味をもつきっかけになったと思う。

https://zenn.dev/ymrl

• Inclusion
  • Accessibility in the physical world is the degree to which an environment is usable by as many people as possible
  • Web accessibility is the degree to which a website is usable by as many people as possible

• Universal design is the design of products and environments to be usable by all people, to the greatest extent possible, without the need for adaptation or specialized design
• The distinction between universal and accessible design
  • Accessible design considers the needs of people with disabilities
  • Universal design considers the needs of a diverse human population

• Screen readers
  • Job Access With Speech (JAWS)
    • the most capable and well-known screen reader of its kind
    • costs around $900
  • Apple’s VoiceOver
  • Microsoft’s Narrator
  • NVDA (NonVisual Desktop Access) for Windows
  • Linux Screen Reader (LSR)
  • Orca for Linux
  • Window-Eyes

• Keyboard navigation describes a situation when a person uses only a keyboard to access a computer or site
• Most keyboard-based web browsing uses the Up and Down cursor keys for scrolling, the Tab key for moving between interactive elements, and the Space bar or Enter key for interaction
  • Screen readers will often map keys to different, more contextually relevant, commands

• Beyond screen readers
  • Navigation hardware
    • Touchpads and touchscreens, upright or vertical mice, trackball or rollerball mice, even foot-operated mice
  • Switch inputs
  • Eye trackers
    • Dwell Control
  • Speech recognition
  • Screen magnifiers
    • Images of text render poorly when zoomed, and should be avoided

• Making our sites accessible starts with the understanding that people access the web differently, and continues with every member of the team ensuring their output is inclusive

Disabilities is an umbrella term, covering impairments, activity limitations, and participation restrictions. An impairment is a problem in body function or structure; an activity limitation is a difficulty encountered by an individual in executing a task or action; while a participation restriction is a problem experienced by an individual in involvement in life situations.
—World Health Organization

• When we’re designing for the web, thinking of the person before the disability helps us focus on universal design: we consider the needs of our diverse audience rather than create a false separation between “people without disabilities” and “people with disabilities.”

• Types of disability
  • Visual impairments
  • Auditory impairment
  • Motor impairments
  • Cognitive impairments
  • Vestibular disorders and seizures

• Visual impairments
  • Color blindness
    • affects up to 8% of men and 0.5% of women
    • cannot see a particular color or distinguish certain colors from one another
  • Eyesight loss

• Auditory impairments
  • Conductive hearing loss occurs when sound can’t get to the inner ear. It’s usually caused by a blockage or abnormality in the ear. This type of hearing loss makes sounds quieter, but not usually distorted.
  • Sensorineural hearing loss (sometimes referred to as sensory, cochlear, neural, or inner-ear hearing loss) is caused by damage to the nerves in the ear, distorting sound and making speech harder to understand.

• Motor impairments
  • An enormous range of conditions can cause motor impairments
  • Motor impairments can also mean that user response time is slow: interfaces requiring interaction at a particular time, especially in games and animations, may result in missed cues

• Cognitive impairments
  • Cognitive issues that are particularly relevant to the web
    • Memory
    • Attention
    • Problem-solving
    • Text processing
    • Math processing
    • Visual processing
  • Learning disabilities
    • Dyslexia is a general term for disorders that result in difficulty in learning to read or interpret words, letters, and other symbols
  • Literacy
    • The global adult literacy rate was 85% in 2015, with 757 million illiterate adults

• Vestibular disorders and seizures
  • affecting as many as 35% of adults aged forty years or older in the United States
  • causing dizziness, vertigo, cognitive confusion, and hearing and visual disturbances
  • Animations, unconventional scrolling, and parallax backgrounds can cause headaches, dizziness, and nausea
    • help people with vestibular disorders by giving them control over the animation and motion experiences on our websites

• Environmental factors
  • Context has a huge effect on how we use the web
    • browsing with legacy browsers or operating systems
    • browsing with mobile devices, game consoles, and other non-desktop devices
    • low bandwidth or an intermittent internet connection
    • browsing sites that aren’t in our native language, or a familiar culture
    • bright light, rain, or other weather-based conditions
    • noisy or highly distracting environments
    • ultra-quiet environments (like shared office space, libraries, or a home with sleeping babies)

• There are so many little physiological factors that affect the way people interact with the web that we can’t afford to make any assumptions based on our own limited experiences

• Business benefits of building accessibility into your project
  • Findability and ease of use
  • Competitive edge
  • Lower costs
  • Legal protection

• Building your team
  • Web accessibility is the responsibility of everyone who has a hand in the design of a site
  • Leadership and support
    • While we should all be attentive to how accessibility impacts our specialism, it’s important to have leadership to help determine priorities and key areas where the product’s overall accessibility needs improvement
  • Professional development
    • When you’re just starting to learn about accessibility, people in your organization will need to learn new skills and undertake training to do accessibility well

• Scoping the project
  • What is the purpose of your product?
  • Who are the target audiences for your product? What are their needs, restrictions, and technology preferences?
  • What are the goals and tasks that your product enables the user to complete?
  • What is the experience your product should provide for each combination of user group and user goal?
  • How can accessibility be integrated during production?
  • Which target platforms, browsers, operating systems and assistive technologies should you test the product on?
• Documenting your success criteria and sharing it with other people can help everyone understand your aims, both inside and outside your organization

• Research
  • Researching accessibility forces you to delve into the full range of your audiences’ needs—including differing impairments and environments—which will significantly enrich your plan for an accessible product
  • Seeing real people use your product lets you understand their environment, context, needs, and behaviors
  • Be careful not to assume that feedback from one person with a disability applies to all people with disabilities
    • What works for one person might not work for everyone with that disability or for people with other disabilities
  • The work doesn’t stop once you’ve done all this research
    • Research is cumulative

• Maintenance
  • Having an accessibility policy will help you maintain high standards and prevent you from compromising on the basics
  • Good accessibility policies will help:
    • ensure everyone in your organization understands the importance of accessibility,
    • standardize the way your organization approaches accessibility, and
    • prioritize user groups when handling competing needs.
  • Guidelines in your accessibility policy should be:
    • clear and simply written, so anyone in your organization can refer to your policy and understand the implications and their role;
    • hierarchical, so needs are prioritized as primary, secondary, etc.; and
    • testable, so you can easily determine whether your site is sufficiently accessible.
  • The testable criteria in your accessibility policy could be based on the Web Content Accessibility Guidelines (WCAG) 2.0 criteria, or criteria from the standards local to your country

• Affordances are how objects suggest the interactions that can be performed with them—ideally in a way that’s recognizable by users
• On the web, using conventions well makes for a gentler learning curve for new visitors
• Affordances and conventions should inform the design and content of your sites

• When the navigation reflects the information architecture of your site, it gives people a better understanding of where they need to go and offers a preview of other information they might find relevant or interesting
  • Navigation bars work best when they offer a brief snapshot; they become unwieldy if the list of links they contain is too long
• If your navigation needs an explanation, you should probably rethink it—and consider returning to well-established conventions

• The problem is that using “click here” as the language for your links renders the links meaningless for those with screen readers as well as those without. Descriptive linking, instead, helps links make sense out of context, and provides users with a sense of where the link will take them or what will happen after they click. “Read the full article” is a lot more descriptive than “Click here.”

• The primary role of the browser in web accessibility is to connect HTML to the accessibility layer of the operating system

• View the bare HTML structure of any web page by removing its CSS styles
  • A unstyled view of an HTML document approximates the way it would be read by a screen reader—from top to bottom
  • Screen readers can’t skim for patterns and context, so it’s crucial that the content is in an order that make sense to the screen reader, with the most important information appearing first

• Incredibly rich interaction can be created through buttons and inputs, no JavaScript needed

• Progressive enhancement (also sometimes known as adaptive design) defines a minimal experience acceptable on all devices and browsers. Enhancements that optimize the site—for particular technologies, viewport sizes, and sometimes devices—are then layered on top of that baseline. Crucially, these enhancements don’t affect access, ensuring that everyone—even those without fancy devices or the latest browsers—has a good, if basic, experience.

• A related approach is graceful degradation, which might be considered the flip side of the progressive enhancement coin. Graceful degradation is the idea of building for the most capable browsers, and adding fallbacks for the less capable. It’s a concept borrowed from mechanical and electrical systems, designed so that when something goes wrong, the system doesn’t break completely—it just operates in a limited way.

• Progressive enhancement has gained favor over graceful degradation in recent years because the variety of devices and browsers has made it difficult, and unrealistic, to support only a small group of browsers. The capabilities of devices and browsers can differ wildly from one to the next, so layering feature support and enhancements on top of a baseline experience is the easiest way to make the best site for the widest audience.

• Your testing document should contain:
  • testing methods to be used, and when they’ll be used in the process
  • how the testing methods will support the production team’s progress toward the usability targets
  • how the test results will be documented
  • how the test results will be fed back into the process to improve the product

• Heuristic testing means testing against existing goals and guidelines, often conducted by the people already working on the project
  • Reviews of early designs and prototypes
    • Heuristic evaluations test an interface against a set of guidelines such as the WCAG, but may also take into account any common issues that aren’t covered by the WCAG
    • Cognitive walkthroughs test the interface against specific tasks, trying to attempt a goal in the same way a user would
  • Code reviews
  • Automated tests

• Device and browser testing involve testing your site across combinations of devices, operating systems, and browsers
  • You need to be able to justify the devices, browsers, and assistive technologies you’ve chosen for testing

• Validators and checkers
  • https://validator.w3.org/
  • https://wave.webaim.org/

Testing is really another kind of research. Testing isn’t what you do at the end of a project to prove that you’re brilliant at your job—it’s the beginning of another iterative cycle in your project’s life. Test early and often, and then test again. Regular testing will reassure you that you’re heading in the right direction, or give you new targets if the accessibility falls short.

• In the United States, the law most relevant for accessibility is the Americans with Disabilities Act (ADA)
• In the UK, the relevant accessibility law is the Equality Act
• Section 508 is an amendment made in 1998 to the US Rehabilitation Act of 1973
• The European Union has a similar draft regulation to Section 508 in its European Accessibility Act

• WCAG 2.0 principles
  • Principle 1: Perceivable—information and user interface components must be presentable to users in ways they can perceive
  • Principle 2: Operable—user interface components and navigation must be operable
  • Principle 3: Understandable—information and the operation of user interface must be understandable
  • Principle 4: Robust—content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies

• WCAG criteria levels
  • Level A: the lowest (minimum) level of conformance
  • Level AA: the middle level of conformance, satisfying both Level A and Level AA criteria
  • Level AAA: the highest level of conformance, satisfying Level A, Level AA, and Level AAA criteria

It can be easy to treat guidelines as checklists—criteria to simply tick off, convinced of our compliance. That might satisfy a court, but it ignores the principles underlying the guidelines.

As we wrap up our time together, I have a final request for you: talk about accessibility more! If you do, others will too. My one wish for the web is that people consider accessibility in the same way they think about web performance. The performance implications of a new tool or technique are always mentioned in blog posts and articles. Wouldn’t it be great if the same were true for accessibility?