In Attendance:
- Aaron Jorbin
- Emil Uzelac
- Kevinjohn
- Amy Hendrix
- Michael Fields
- Dave Martin
- Jake Goldman
- Isaac Keyet
- George Stephanis (note taker)
Discussion Notes
Kevinjohn brought up the initial concern that, in the EU, some groups can’t use WordPress, as it hasn’t met some accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) requirements for a few releases now — but we’re close. Have to meet AAA standards for EU.
How’s the back-end for accessibility? Jorbin brought up that he, Nacin, and Koop sat down with a blind user and did accessibility testing of post screen — everything was properly set up except for the post box itself.
(aside: question of if we should / how we could make it easier for front-end users to be accessible is nipped in the bud for later discussion)
Amy Hendrix brought up the question of new accessibility tests for themes — which is a work in Progress
What is the accessibility group? https://make.wordpress.org/accessibility/
Aaron Jorbin pointed out that we should get accessibility experts more involved in WordPress. By bringing the accessibility community into the WordPress community, we all benefit.
One of the challenges is that it is hard for much of the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team to test accessibility patches do to them not having copies of accessible technology software. A good deal of the software is commercial (or only runs on one operating system) and few people have copies to test patches against.
(aside: someone pointed out that it would be nice to automate patch applying by generating trunk installs on the fly and applying patches to them, to enable less-technically-minded people to contribute to testing. Perhaps on wpusertesting.com or similar?)
We need to migrate from being reactionary to proactive! While there are a couple patches for 3.5, we may need a set of guidelines for a11yAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) standards, the same way that we have php and css guidelines.
It would be very useful to add a high-contrast theme for the admin UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing..
We also need to emphasize the reasons to focus on accessibility — better SEO results and marketing, for one. The W3CW3C The World Wide Web Consortium (W3C) is an international community where Member organizations, a full-time staff, and the public work together to develop Web standards.https://www.w3.org/. has an article on the web accessibility business case.
(aside: could we possibly include an APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. for toggling high contrast mode on or off?)
It would be nice if TwentyThirteen was designed accessible as a number one priority, but how do we get there? We need someone to take responsibility.
Isaac Keyet mentions that mobile apps are mostly compliant, but it’s more dependent on the platform that you’re on.
Drupal contacted the governments and asked what they needed to do to become fully compliant. We need to get data / feedback that lists what we have already, and what we need to be properly up to spec.
Standards — which ones should we focus on? There are multiple options.
Checklists to compare patches against would be really helpful! Accessibility is much more than that, but it’s a tool that could help devs not as familiar with Accessibility. Not a solution.
Should we add a `not-accessible` or `needs-accessibility` tag in tracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/.? These could make it easier and puts accessibility on the same level as UI or UXUX UX is an acronym for User Experience - the way the user uses the UI. Think ‘what they are doing’ and less about how they do it.. It’s not a feature, it’s a core asset.
We need more accessibility talks at WordCamps … bring accessibility into the popular mindset.
TAKE AWAYS:
- Add a section to the Handbook.
- Add in some requirements for patches that they be tested against accessibility guidelines.
- Need someone to take ownership for things going forward.
- Page on .org talking about what certifications we meet.
- Challenge TwentyThirteen to be designed with accessibility as it’s number one Priority.
Action Item:
We want to add WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org//accessibility which will be a one stop shop for successes we’re having and ways people can get involved. This is partially inspired by The Drupal Accessibility Page.