This week in WPA11y – June 5, 2017

WordCamp Europe

Topics Community Summit (CS):

  • New developments for the the Editor, and how to safeguard it’s accessibility – (Core)
  • Technology version support policies – (Core)
  • How to involve more developers in helping with the accessibility tickets
  • How to proceed with the handbook
  • Addition: Considering the shift towards JS-based interfaces, we should consider to review and update the accessibility coding standards

@joedolson will write up a draft for the updated coding standards, for us to discuss on the CS.

Contributor day:
All plans are in the Google Doc: List of goals for Contributors day in WCEU.
And the is also a list of a11y tickets to pick from.

Testing

After June 26th we will start testing again. For this patches and plugins will be installed on our test server and given to the test team.

To test:

Next meetings

There won’t be a meeting or bug scrub on June 12th (due to WordCamp Europe).

 

#accessibility-team-meetup

Summary meeting WPa11y team, November 21 2016

Attendees: @afrecia, @cheffheid, @joedolson, @sami.keijonen, @rianrietveld, @arush, @trishasalas and @antotrifiroconaccento.
New to the meeting: Bonnie Boden (@bdd) and Terrence Gonsalves (@tegonsalves), welcome!

Plans for WP 4.8

Main focus: Settings API,  Uniform search and ticket 26601:

Fixing accessibility and semantics of the settings API. Plan is to make a parallel version 2 to prevent plugins from breaking. There are a couple issues with the Settings API:

  • It outputs a table with labels and form controls in table cells
  • It doesn’t handle so well checkboxes, group of checkboxes, and radio buttons.
  • No fieldsets or legends.

Related ticket: #38734 Dogfood the Settings API

Uniform search, related ticket: #31818 Uniform Search Form Display/Experience

Finish work in ticket #26601 Inappropriate content in headings on admin screens

ATAG review

ATAG means: Authoring Tool Accessibility Guidelines (ATAG) 2.0 and Joe Dolson reviewed how well the WordPress Admin does for those guidelines. He will write a report with the complete results later, here already a quick summary:

  1. Video/image modal does not announce selection to AT in visual editing.
  2. Video/image modal toolbar does not have valid labels (labels are on wrapper divs as aria-label, actually focusable element is empty)
  3. Method to associated video captions programmatically with media library object does not exist
  4. Animated Gif images should not autoplay in visual editor
  5. Alt attributes should be searchable in media library
  6. Should be possible to set custom style settings in editor
  7. Publishing content must not strip out added accessibility information, such as ARIA attributes
  8. Accessibility information should be mentioned in documentation: e.g., instructions on how to add an image should mention the need for alt attributes.
  9. There is no method to structure and publish accessible tables.
  10. There is no method to structure and publish accessible forms.
  11. Meta boxes order cannot be changed from the keyboard; drag and drop only

And that will mean a lot of new tickets 🙂

Next meeting will be Monday November 28 at 18:00 UTC

#accessibility-team-meetup

a11y update week 37 2016

Summary meeting WPa11y team, September 2016

Documentation

Work is in progress by @trishasalas, @iamjolly and @rachievee.

Theme review

There are now 112 accessibility-ready themes in the repository. 80+ Waiting for a review, still a long waiting list. More help with reviewing is most welcome. @iamjolly will help this week and also Caroline Nymark had been doing reviews.

@joedolson made a minor tweak to the guidelines last week at @afercia‘s request: adding type=button to the best practice example for creating action buttons in themes.

<button class=”menu-toggle” type=”button”>Menu</button>

Twenty Seventeen

The new theme Twenty Seventeen is available at GitHub:
@davidakennedy will monitor the work and give the team a ping when it’s ready for an accessibility review.

Select2

There is some progress in the Select2 accessibility issues Andrea posted on GitHub.

Kevin Brown :

In the next couple of weeks, we plan to work with others to get Select2 to be accessible under the most basic use case: a flat dropdown that is searchable. Since that appears to be the use case that most screen readers support.

Tickets

#34635: WordPress image’s title is not alt
We discussed in length a solution to prevent nonsense for an alt attribute and to be able to set an empty alt=””. @joemcgill is going to work on a patch.

Open floor

@davidakennedy: I’m trying to research for Twenty Seventeen is whether it’s possible/advisable to remove the explicit ARIA roles in Twenty Seventeen. Like, role="banner".
In the team we have very different views on this. We need to research this further (browser support/AT support/usage etc).

Bug scrub

#38023: Menus screen: simplify the Menu Settings controls.
The form layout for the menu settings is done with <dl>.
It would be great to use proper form elements instead (fieldset, legend). We have similar constructions on other pages, maybe find a consistent way to do them. Needs research, set to 4.7

#16206: Comment text not marked as required
and related
#37331: New site form has non-required fields that have to be filled in.
We’ll have a go at fixing these two for 4.7

#16413: Settings page needs HTML refactoring and UI improvements
This could get some traction if the Fields API gets into core; that would be a starting point for redoing these types of pages, so we wait for that (not in 4.7 yet, according to @sc0ttkclark).

#18801: Accessibility Enhancements to Settings AP
It’s basically the same issue as #16413.

#21414: Use the “Keyboard Shortcuts” checkbox in the user profile to turn on/off all custom shortcuts
Seems it’s in good hands at the moment.

#21583: Improve discoverability and visual design of Screen Options and Help Panels
It would be nice to get this into core, but it’s a lot of work and will take some releases.

#accessibility-team-meetup

a11y update week 34 2016

Summary team meeting WPa11y team, August 23

Focus for WP 4.7

@davidakennedy suggested: “Since new user experience will be a focus: maybe there’s a11y items we can improve related to that? First-time installs, theme activation, etc.”. And we agreed that this is a good idea.

Some suggestions that came up:

  • let the test team do the famous 5-minute install with different AT
  • focus exclusively on the experience with default themes
  • plugins: only install, active, deactivate, remove
  • check for and address any existing problems
  • see whether there are any major changes proposed for WP 4.7 and test those
  • hashtag #a11y-firstinstall for tickets

@trishasales and @rianrietveld have time for this.

Theme reviews

@joedolson completed a couple reviews in the last two weeks. Robert Jolly (@iamjolly) is joining Joe and David in reviewing themes for the accessibility-ready tag.

Documentation

Robert Jolly is also going to help Trisha and Rachel Vasquez (@rachievee) with a high level overview and some Project Management for the handbook. The goal is to reinstate the hierarchy that started at WordCamp US and build/modify as needed. There will be a Google hangout next Thursday to get this started.

Open floor

Joe brought up the following:

“We have a list of accessibility related plugins. These are not all of the accessibility-related plugins in the repository. Some plugins are not helping accessibility and a few are even harmful. Do we, or should we have a specific policy governing which plugins we’ll list there?”

We agreed on not having an official certification/approval system for plugins like we have for the accessibility-ready themes.
Joe, Robert and Rian are going to look at the plugins tagged for accessibility and investigate if there are plugins that claim to improve a11y but are actually harmful or doing things that are really not beneficial.
Also we can extent the list with plugins on Useful Tools we think are good.

Bug scrub

This week there was no bug scrub, someone needed a holiday…

And other news that came by during this week

  • Modern Tribe is now sponsoring time for Trisha Sales to spend on work for the accessibility team.
  • Rachel Carden (@bamadesigner) published a nice plugin wa11y , for testing a website for accessibility with e.g. WAVE and Tota11y.
  • @michael.heuberger is working on a plugin using JavaScript to integrate a video in a form submission. This way deaf users can submit their response in sign language.

#accessibility-team-meetup

WP a11y update week 31 2016

Summary team meeting WPa11y team, August 1

Team meeting in Slack.

Retrospective and looking ahead

In @afercia’s words: Since the release cycle is now in RC time this would probably be a perfect time to think at the past months activities, what went well, what could be improved, do you feel there’s anything that makes contributing difficult for you, is there anything you feel it should be done differently? Maybe also start thinking at (realistic) plans for the next release cycle and check time and resources availability for the next months. Maybe we could introduce this kind of “retrospectives questions” after each release cycle.

What went well?

  • We’re alive, more or less in good shape, we improved a bit accessibility on WordPress
  • Having a focus each release went well, like heading structure, colour, title attribute
  • Introducing the bug scrubs – even if it doesn’t directly fix tickets it does bring order to the madness
  • Attending and speaking at WordCamps was useful
  • Accessibility tables and workshops on contributor days at WordCamps

And from our sponsors:
WP Site Care sponsored Andrea and Rian to go to the community summit and WCUS15. Yoast sponsors 25% of Andrea’s time to do a11y core work. And (spoiler alert) Rian will be sponsored too for 25% as from mid August.

What can be improved on

  • We don’t have time resources, people, and skills to start managing accessibility projects. We work on the existing issues but need to start thinking at bigger plans. Patching and patching is someway expected in a so large project with outstanding accessibility issues, at the same time it would be great to start bigger projects.
  • Accessibility is not part of new features since the initial development steps, but something added at a later stage

Do you feel there’s anything that makes contributing difficult for you?

  • Everyone: lack of time
  • Some of the new features, like Shiny Updates and Twenty Sixteen and Fields API, were initially developed on GitHub, that makes things more difficult to follow different things on different places
  • The difficulty of monitoring accessibility is that it involves every part of core development. Maybe we need to focus on training the developers, and not in fixing stuf ourselves.
  • A couple more coders would help too
  • The lack of proper screen reader accessibility of Slack makes it difficult for @arush to contribute.
  • There are accessibility issues on the form to create new tickets and to comment on tickets in Trac, which makes it difficult for people using assistive technology to contribute.

Plans and ideas

  • Spend more time on WPa11y core work and documentation
  • Focus on education developers and designers
  • Training for theme reviews accessibility-ready tag
  • Extend and improve the pattern library
  • Give more workshops on WordCamps
  • Do more a11y audits on core, with recommendations to fix (and not fix ourselves)
  • A monthly or quarterly or whatever worldwide a11y contributor day, like the translation day, use also the global a11y awareness day
  • A11y audit on the Trac templates
  • Involve more assistive technologies users on trac, but before that the Trac issues must be solved
  • Start a featured project (the Media maybe?)

Open floor

Maybe we need a statement on Make/Accessibility that the accessibility team is independent and not connected to any company for assistive technology or test software. This to prevent to be claimed by companies for our voluntarily work on open source.

Bug scrub, August 1

We discussed tickets labeled accessibility and with status awaiting review.

Bugscrub in Slack.

#37513: Admin bar sub menu items dashicon and screen readers and
#37511: Dashboard activity widget: hide the “No activity yet” smiley from assistive technologies
Screen readers behave differently with CSS generated content, for example VoiceOver gets CSS generated content icons as “text” element. The W3C spec says is that something is probably going to change in the next future and CSS generated content, including dashicons, will be probably announced as content by assistive technologies. We should monitor this as a general issue for all the CSS generated content used in WordPress.
Set both tickets to 4.7-early

#37486: Make emojis accessible
Andrea opened this ticket mainly to start a discussion about Emojis. This needs research, Rian will have a go on this.
Set to Future release.

#36925: Media views: introduce a “Heading” view for better accessibility
Set to future release, there is already good work in progress for this ticket.

#36474: Revamp meta boxes
A ticket for the UI/design team to handle, the label accessibility is only added to keep informed about relevant UI changes.

#36447: Responsive preview icons in Customizer need tooltips
We agreed that tooltips are necessary. Best = Icon + text and Second best = Icon + aria-label/tooltip. Good example is GitHub handles the icons with aria-label and tooltips. @arush mentioned grease monkey script  to help those who aren’t power users deal with them on the NVaccess Github
Set to Future Release and assigned @iamjolly as owner

And other news that came by during this week

Josh Pollock, the plugin author of Caldera Forms, started working on fixing accessibility issues in his plugin. You can follow his progress for Caldera Forms in GitHub. Feedback is welcome.

#accessibility-team-meetup, #bug-scrub

Team Meeting April 11, 2016

Just before the 4.5 release we looked back and ahead on the work we do as a team. The following idea’s where discussed:

We need more coders (Andrea Fercia is doing way to much on his own), and we have to find a way to find and keep new coders for our team.

Be less focused on specific tickets, and more focused on tasks. And have somebody responsible for managing a goal, and keeping on top of all tickets pertaining to that goal. That may include asking somebody else to write it or work on it, but that person is keeping on top of that particular goal and whether it’s on track.

Start a mentor program for new contributors, teach them accessibility and have someone available to answer questions, assign a coder a ‘mentor’ to ping on Slack.

Find a way to get funding for the team. Almost all the work is done in our free time and this is part of the reason we are short of hands. Brainstorming about funding:

  • Crowd fund, for example Patreon.com
  • WordPress Agencies
  • Universities
  • WordPress Foundation
  • Accessibility organizations

Joe Dolson is preparing a survey regarding WP and Accessibility, so we can gather data. What AT are people using (they should complete the survey once for each combination they use with WP), their pain points, where they feel WordPress is strong/weak, overall impressions of how WordPress has changed since they started using it including data about when they started using it, what version they’re currently using, if they haven’t updated, etc…

Tickets cleaup

To investigate which tikets need work and which goals we need to set for future releases we organize a tickets focussing accessibility review session on Saturday. A bug gardening, ticket cleaning, bug scrub meeting on Saterday April 16 at 13:00 UTC in the accessibility channel in Slack. Everyone is welcome to join us.

Review the meeting at Slack

#accessibility-team-meetup, #weekly-meetings

Summary Team Chat for Februari 8, 2016

Core accessibility coding standards

After discussion with @jorbin some last changes where made on the Accessibility Coding Standards. @jorbin will bring it up at the next Core meeting to make sure there are no objections there.

Documentation

@hearvox finished the Quick Start Guide in our Handbook. @rachievee is working to add other pages to expand on topics from the Quick guide that need longer explanations.
@trishasalas organizes a one time meeting on Februari the 22nd 17:30 UTC to discuss finalizing (for now) the structure for the handbook. In the meantime Trisha is going to begin writing the Plugin section of the Handbook.

Accessibility Test Team

Nimbus Hosting is so generous to sponsor the #wpa11y team with a VPS server. Here we can install a production, nightly and trunk version of WordPress and also have SVN and SSH access.
We will set the server up next week, then we’re up and running again and resume sending tests to our team.

Accessibility-ready themes

Joe started to work on a fork of the theme unit test data, focused on accessibility testing – a smaller set of data, eliminating false positives in the data, etc. He will let us know when it’s usable.

The post with the requirements for the accessibility-ready tag has been improved. There is now more information on how to test a theme to help theme authors better.

Tickets

@afercia: Investigation about color contrast continues.

#26601: Inappropriate content in headings on admin screens.
@trishasalas will write an new, refresed patch, keeping the add new link visually on the same place but placing it in the HTML outside the h1 heading

From Februari 16 on we will have an extra meeting to work on tickets. The group has grown so much last year that we need more time to discuss and work on core tickets then we have now in the regular meeting. This ticket meetings will be every Tuesday on 18:30 UTC.

And from everybody in the a11y team:
We wish @accessiblejoe a good and quick recovery!

#accessibility-team-meetup, #weekly-meetings

Summary Team Chat for January 18, 2016

Documentation

@trishasalas and @rachievee have been working to organize the docs and create some new drafts in the handbook. Work in progress.

Tickets

#34780: Updates screen: Plugin and Theme tables improvements
We discussed removing the scope from the th and td first and then think of a way to set up the layout, not in a table but in another, more semantic way.

#34625: wp-login.php site title link points to wordpress.org
We need to research if themes and plugins would break if the title attribute on the logo is removed. Maybe an option is to have no title output by default for the filter. @arush volunteered to own the ticket.

#35313: Remove title attributes: Posts, Pages, and CPTs screens
What to do with icons with a title attribute? For a sighted desktop user, the title attribute is the only indication what the icon means. There are many places where the link is just shown as an icon, and here the totle attribute was useful. We discussed how to solve this: we need to develop a core method to handle tooltips effectively. Andrea will open a ticket for this.

Color contrast: Some browsers do not support the styling of checkboxes and radio buttons. This means that in some browsers give that borders a poor contrast by default.

@afercia started to open tickets about the color contrast like #35497: List tables: Post format links improvements
@rianrietveld will make a list of all the color issues in the Admin, we can use as a reference to open new tickets.

Accessibility guidelines for core

@joedolson had some comments on the core a11y guidelines; just a couple, minor changes for clarity. Basically well received by the core team. Joe is waiting for a few more comments from members of the core team that did not have to chance to look at them yet.

#accessibility-team-meetup, #team-reps, #weekly-meetings

Accessibility Handbook Update

Today I started to add subsections to the Accessibility Handbooks Contributor Spreadsheet and while I was looking over other Handbooks (Docs in particular) I decided it might be best to streamline content even further to separate Informational content about the team, mission, etc from the actual Resource for Developers.  Documentation has a Docs Handbook for their section as well as links to other Handbooks for Developers.  I’d like to see Accessibility follow that format and have reached out to @sewmyheadon and @topher1kenobe to get some insight into how they approached the process.

Join us in the meeting today, January 11 @ 18:00 UTC or comment here if you have any thoughts or additional ideas to help us move this project forward!

Thanks to everyone involved for all the help so far!

#accessibility, #accessibility-team-meetup, #f

Summary Team Chat for January 4, 2016

Tickets

#33952: get_search_form() accessibility improvements

The main issue when using `get_search_form()` is redundancy.  A lot of  “search, search for… search… search button”

Given that `get_search_form()` is used in both the admin & the front end as well as by themes it was determined that we will look at a uniform search for the 4.6 release.  In the meantime, we will remove the `title` attribute for a quick ‘win’.

#35187: Remove title attributes: the terms List Table

The current structure is semantically inaccurate but fixing it will require some design input to rework the list table layout. We have decided to stick with the original plan to remove the title attributes and find solutions for other issues at a later time.

Accessibility standards for core

@joedolson posted an updated link to the Accessibility Standards for Core document from last week. https://docs.google.com/document/d/1iySvDJ4duHYt6YlnnjnBNbU5LKAn1uRBMH8FKAfmswE/edit He has asked anyone who is interested to review and make comments.  He will eventually communicate with the core team to get this information into the Core Handbook.

Documentation

During the next week I will begin adding sub categories to the sections in this spreadsheet. https://docs.google.com/spreadsheets/d/1tOYzFn9vc7Ff4yGBmDajelrl7XMDUz4PR5H2lB4exI4/edit.

The hope is to get more of a structure in place to make it easier to contribute.  So that, rather than needing to figure out where content will go you can pick a subcategory page and focus on the content for that page.
We also discussed consistency as well as what the need to be sure that any of the content we link to from the handbook is vetted by the Accessibility Team as a whole.

Next meeting

Next meeting will be in January 11, 2016 at 18:00 UTC

#accessibility-team-meetup, #weekly-meetings