Week in WPa11y, April 5 -11 2017
Results Editor survey
105 respondents use a screen reader. 94 of those people feel the screen reader experience is sufficient or better. Other assistive technologies used by the respondents include: On-screen keyboards, alternative input devices like wands & sticks, voice recognition programs, screen enlargers, text to speech synthesizers, and braille embossers.
Some quotes from the survey questions about accessibility issues with the Editor:
You need to add more notifications for screen reader when somethings change on the page.
I reached and pressed the Publish button and forgot that there are meta boxes after that. So then I had to fill up the category and tags then shift + tab to go back to Update the post.
Andrea: There were a variable number of 6-8 participants at the a11y table during the day. That’s a huge number for a11y during contributor days. Most of them were beginners so we’ve spent most of the time on introducing to accessibility. Run some keyboard accessibility testing, followed by an introduction to screen readers basic principles. In the last part of the day we’ve discussed all together #35497 – List tables: Post format links improvements.
Dana Donato (@danuccia) joined the WPa11y meeting in Slack after joining the contributors day in Torino. She wants to help with tickets.
Summary of the discussion during the Settings API meeting
Notes by @afrecia:
- use more settings sections to group fields that belong together (note: sections that group logically related controls should be fieldset elements)
- GitHub flow: use distinct branches for design/layout changes and Settings API improvements
- planning new GH issues to open
- CSS naming conventions: the general issues here are trying to establish easy and maintainable patterns, taking into considerations the CSS Roadmap
- keep selectors specificity as low as possible, avoid overqualified selectors
- @helen suggested selectors should also provide a context:
- “In an ideal world, you would have some baseline stuff for elements themselves, and then you scope upward to apply specific stuff based on context as needed”.
- “The goal should be for people (devs) to not have to do anything involving class names or CSS the vast majority of the time.”
- @helen will try to start a doc to dump thoughts on the best option we have for CSS naming
- CSS classes to target stuff in JS: they should be separate from classes used for styling
- CSS classes for state naming for JS (e.g.
Proposal for a new a11y-task ticket: CSS generated content.
We’ve discussed a few times the issue about font icons or other characters generated with CSS
::after. In some cases, they can be announced by screen readers. At the moment, the only way to make sure they’re not announced is using a
<span aria-hidden="true"> element and target that with
::after rather than the main element. We should progressively introduce this as a best practice and also make people aware of the problem.
Andrea will write the ticket and @trishasalas will do research on how CSS content is used in core.
Note: a11y-task tickets are issues that should be addressed but we don’t have time and resources to tackle right now. Starting a discussion about them would be valuable though.
Current work a11y team
- Gutenberg: as soon as the featured plugin is released we will test it.
- Tag Cloud adjustments (tag-cloud): #35566 #40187 #40186 #40184 #40138: @samikeijonen and @davidakennedy
- Settings API plugin: @flixos90 and @afercia
- Colour contrast in the Admin: @adamsoucie
- Required fields @rianrietveld
- Non-link links: @cheffheid
- CSS generated content: @trishasalas
- Remove title attribute in the Admin: any volunteer
Both are also installed on our test server at wpaccess.org
Interesting reads this week
- How to Design for Color Blindness by Robyn Collinge