User:Montehurd/accessibility
I'm using this page to aggregate some notes I've taken regarding accessibility.
Introduction
[edit]The best accessibility introduction I've found is compiled by the Australian government and may be found here.
Perspectives
[edit]These short videos are an excellent place to start when thinking about accessibility improvements.
Guidelines
[edit]WCAG
[edit]The W3C Web Content Accessibility Guidelines (WCAG) outline best practices for designing website which are "perceivable, operable, understandable, and robust".
Another good summary of the W3C WCAG document.
WAI-ARIA
[edit]The Web Accessibility Initiative - Accessible Rich Internet Applications (WAI-ARIA) provides ways for web applications to interface with assistive technologies.
A basic intro with emphasis on using semantic elements vs plain DIVs for everything.
An important point about WAI-ARIA attributes is that they don't affect anything about the web page, except for the information exposed by the browser's accessibility APIs (where screenreaders get their information from). WAI-ARIA doesn't affect webpage structure, the DOM, etc., although the attributes can be useful for selecting elements by CSS.
Tutorials
[edit]Development
[edit]Extremely well produced 30 part technical web development accessibility series.
I highly recommend using the playback speed keyboard shortcuts mentioned below - you'll save so much time by watching the series at even 1.25 speed. And you'll be using an accessibility feature!
Toolkits
[edit]As referenced above, the Australian government's wide-ranging, detailed and polished accessibility website has sections for managers, designers and developers.
Tools
[edit]axe web UI accessibility testing automation
[edit]axe-core
[edit]axe is open source, well maintained and relatively easy to set up and use.
Framework repo
In-depth tutorial video
Another great tutorial video
axe-webdriverjs
[edit]"Provides a chainable aXe API for Selenium's WebDriverJS and automatically injects into all frames."
Framework repo
Tutorial video
axe-cli
[edit]Framework repo
Tutorial video
axe browser extensions
[edit]Accessibility is for everyone
[edit]Everyone can benefit from rich accessibility features.
Keyboard shortcuts
[edit]Keyboard shortcuts are a great example. As part of this research I've started using the following keyboard shortcuts (on macOS).
Wikipedia
[edit]Control-Option-G to open the Wikidata item for an article was neat!
Control-Option-P to show edit preview is handy. Fully dismiss the preview with the escape key.
Youtube
[edit]As I've watched various accessibility videos these shortcuts have proved immensely convenient.
|
|
Safari
[edit]Command-Shift-R Opens a very nice "Reader mode".
Phabricator tickets
[edit]T2477 Access key issues
Tickets tagged with "accessibility"
T232638 Accessibility checks for GrowthExperiments extension
Wikipedia Projects
[edit]Articles with accessibility problems
Articles with color accessibility problems
Accessibility section in Wikipedia Manual of Style
Accessibility and usability cleanup
Accessibility guide for developers
Screen readers
[edit]NVDA for Windows
[edit]Demo installing and using for development
Apple VoiceOver
[edit]macOS VoiceOver training may be found at:
"System Preferences > Accessibility > Open VoiceOver training"
macOS has a simple VoiceOver toggle - hold Command and triple-click the Touch ID button
Potential steps to improve Wikipedia accessibility in various areas
[edit]Editing
[edit]Can we give editors instant feedback on whether their edits introduce any accessibility issues?
Automation
[edit]Can we add (or encourage adding) tests for all extensions so developers can easily know if their work is accessible?
Template usage auditing
[edit]Can we audit what accessibility issues templates already exist, how widely they are used, and how their usage is distributed?
Articles issues auditing
[edit]Can we audit all articles for their accessibility "scores" (maybe just a count of aXe violations detected?) to get a sense for how widespread article issues are? If this number is greater than the number of articles with accessibility-related templates it may provide an opportunity to use accessibility-related templates more widely.
Notes
[edit]Rough notes, thoughts and questions which arose while digesting the resources above.
I need to clean these up :)
https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Accessibility#Resolution
Is there any report on the percentage of articles which scroll horizontally at 1024*768?
https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Accessibility#Text
Can we get stats on use of "unpronounceable symbols such as ♥" ?
Same with line breaks:
"Do not insert line breaks within a sentence, since this makes it harder to edit with a screen reader. A single line break may follow a sentence, which may help some editors."
Same with specifying font size in absolute units vs percentage:
https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Accessibility#Font_size
"Size changes are specified as a percentage of the original font size and not as an absolute size in pixels or point size."
"Avoid using smaller font sizes within elements that already use a smaller font size, such as infoboxes, navboxes, and reference sections."
And links:
https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Accessibility#Links
"Do not use Unicode characters as icons; use an icon with alt text instead. For example, a character like "→" can not be reproduced into useful text by a screen reader, and will usually be read as a question mark."
And lists which jump more than one level:
https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Accessibility#Lists
Could we score articles for colorblindness friendliness?
https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Accessibility#Color
Perhaps look at any text which has a non-black foreground color and for each type of colorblindness have a score which looks at how the text foreground color contrasts with its background color?
Could show "reader view" in iOS app by just using "SFSafariViewController" with "entersReaderIfAvailable = true" ? with mobile web url?
https://stackoverflow.com/a/49327465
Could we have a view which just shows you what headings a screen reader would pick up?
https://www.youtube.com/watch?v=Vx1vSd5uYS8&feature=youtu.be&t=894
https://dequeuniversity.com/assets/pdf/screenreaders/nvda.pdf Keyboard reference
Do any of these conflict with wikipedia shortcut keys?
Does Wikipedia expose "landmarks" appropriately? Could these be better?
Wikipedia doesn't seem to handle initial tab well (safari):
Could test for ensuring no offscreen content can capture focus?
Focus can be "hidden" in offscreen fields
Ensure can do simple navigation with a screen reader:
Ensure "if something is dynamical added to the page than focus is directed to it"
Using aXe chrome extension for quick accessibility audit:
Recommends to use aXe to add some accessibility regression tests:
Enable chrome devtools experiments:
Really good example of labeling for accessibility:
( Text by a checkbox doesn't provide any context for the checkbox to screen readers. )
Could be good for attaching to tickets where I discover lacking labeling.
Aria-labeled-by can compose information presented to screen readers (so cool!):
Aria:
"Allows you to specify attributes on elements which then modify the way those elements are translated into the accessibility tree"
Will let you create accessible widgets which are not possible using plain html"
"role=alert" used to ensure when things are added dynamically they are announced to the user
https://www.youtube.com/watch?v=88tfx3jLV_M&list=PLNYkxOF6rcICWx0C9LVWWVqvHlYJyqw7g&index=14
Super good reference when developing custom html widgets (ala OOUI)