#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.
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.
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.
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 will be in January 11, 2016 at 18:00 UTC
Hi accessibility folks! Thanks for all your hard work and contributions in 2015. Could you contribute few more minutes to fill in the 2015 contributor survey? It will help us establish some baselines around the contributor experience so that we can see how things change over time.
**This is being posted to all the Make teams, so if you subscribe to a bunch of p2s and keep seeing this post, know that you only need to fill the survey in once, not once per team.**
The survey is anonymous (so you can be extra honest), all questions are optional (so you can skip any that you don’t want to answer), and we’ll post some aggregate results by the end of January. It took testers 5-10 minutes to complete on average (depends how much you have to say), so I bet you could knock it out right after you read this post! 🙂
There are two sections of the survey. The first has questions about team involvement, recognition, and event involvement, and is pretty much what you’d expect from an annual survey (which teams did you contribute to, how happy are you as a contributor, etc).
The second section is about demographics so we can take a stab at assessing how diverse our contributor base is. All questions are optional, but the more information we have the better we can figure out what we need to improve. If there’s some information you’d rather not identify, that’s okay, but please do not provide false information or use the form to make jokes — just skip those questions.
The survey will be open until January 15, 2016. Whether you have 5 minutes now, or 10 over lunch (or whenever), please take the 2015 contributor survey. Thanks!
Note: I used polldaddy for the survey and I’m guessing there some accessibility issues. If any of you have trouble accessing the survey, please let me know what the issues are so I can pass it on to the polldaddy developer, and we’ll work out a way for your to respond in the meantime.
#34957 #a11y-focus: Standardizing the handling of :focus and :hover
Moving forward, we’ve established that :focus is the primary transition for when a user interacts with a link or button. :hover is an extension of :focus that comes from a direct action, whereas :focus comes from an indirect action. Because :focus lacks a direct action, it needs to be styled in a way that brings clear visual attention to the element. Michael Arestad (@michaelarestad) is working on the visual update and we’ll move forward with implementing it once we have that complete.
#26601: Inappropriate content in headings on admin screens
Consensus is: ‘Add New Button’ === burn it with fire (agreed on by @michaelarestad) @trishasalas will write a refreshed patch for this.
Next meeting will be in January 4, 2016 at 18:00 UTC
Since WordCamp US we’ve gotten a lot more people contributing to the wpA11y Documentation team. Welcome to Robert Jolly (@iamjolly), Barret Golding (@hearvox), Job Thomas (@jobtex) Scott Mann, Rachel Vasquez (@rachievee) and Nancy Thanki (@nancythanki)!
The idea is similar to the other handbooks in that you pick a section or even a page within that section and you can be the lead for that part of the handbook. As you can see some of the sections have very little content (or none at all in some cases!) so we are in need of content creation as well as editing.
I have also started a basecamp that will hopefully help us to stay organized. If you would like access to that please either comment here with your email address or you can ping me in Slack @trishasalas.
Note that no content has been removed from the Handbook, things have just been rearranged. If you can’t find something you were working on let me know and we can look together 😉
The last month, especially after WordCamp US we’ve got a lot more people contributing to the wpa11y team.
Welcome Robert Jolly, Morten Rand-Hendriksen, Cheo Walker, Sakin Shrestha, Barret Golding, Adam Soucie, Scott Mann and Rachel Vasquez!
We want to keep all the new people involved, not make them feel lost or left out and leave.
Therefore we decided to form working groups, assign one lead and divide the new people in the workgroups, so they know what to do and who to ask for help/work. People can jump in and out of groups as work ebbs and flows.
Task: Find accessibility issues, write and discuss tickets on core trac and code patches for WordPress core.
Lead: Andrea Fercia
Contributors: Joe Dolson, Jeffrey de Wit, Sergey Biryukov, Cheo Walker, Trisha Salas, Adam Soucie, Robert Jolly, Rian Rietveld.
Task: Write documentation about accessibility in our Handbook and on other relevant places on WordPress.org
Lead: Trisha Salas
Contributors: Joseph O’Connor, Barret Golding, Richard Senior, David Kennedy, Rachel Vasquez.
Joe Dolson and Robert Jolly volunteered to review written content.
Task: Test the accessibility of new and exsisting functionallity in and for WordPress core, at the request of the other workgroups and teams
Lead: Rian Rietveld
Contributors: > 75 volunteers, with different kind of assistive tecnology and/or accessibility expertise
Accessibility code standards for core
During the WCUS community summit in Philadelphia we made a start with accessibility code standards for core.
Joe Dolson put a concept for the a11y code standards together.
Please look at the concept and comment on it.
Barret and Trisha are working on a good outine for the documentation, lots of good ideas, work in progress, more next week.
The last #a11y-headings ticket is #26601 Inappropriate content in headings on admin screens.
Joe Dolson will look into this, make a decision on how to solve this issue. On the WCUS contributors day we discussed this and the outcome od this was: First get the link out of the heading, without changing the visual design. And after that is committed, start the discussion of removing it conpletely from the post-new.php / post.php pages.
During the WCUS community summit 2015 in Philadelphia we made a start with accessibility code standards for WordPress core. Joe Dolson put a concept for the a11y code standards together (see below or as Google Doc).
These are the standards expected from new code (like feature plugins) at the time it’s to be merged into core. Our target for released code is WCAG2.0 AA.
Proposed place to put them is the Core Handbook: WordPress Coding Standards, we aim for a short list of very basic things with references to the Accessibility Handbook.
Feedback (in the comment section below) is very welcome.
Concept Accessibility code standards for core:
This document is a list of standards that a WordPress feature plug-in should meet for accessibility in order to be merged into core. These standards are focused on best practices and easily testable concerns.
The expectations for all code released in WordPress is conformance with WCAG 2.0 at the AA level.
Definition of HTML for Controls
Usage of ARIA
Images and Icons
Take a pragmatic approach to HTML semantics. Don’t add semantics purely for the sake of semantics; but if there is an HTML structure that clearly matches the content, use that element. For example, if you have a group of links, it should most likely use a list element.
The H1 is the main heading representing the page title on every core page. For sub sections, use a reasonable HTML heading structure — including the use of heading elements for page sub-sections. Heading markup should not be used for presentational purposes.
Use H2 through H6 to give internal structure to the page.
Don’t skip heading levels.
Don’t add extra functionality inside a heading, like links or buttons.
Semantics for Controls
Controls with a native keyboard interaction (buttons or links) are always preferred. If there is a valid target link for the control, either an in-page reference or a link, then the control should use an <a href=”url”>. If there isn’t, it should use a <button>
Related ticket: #26504 Semantic elements for non-link links
When there are dynamic changes within a page without a page reload you must provide audible feedback with ARIA for important changes, like a successful saving for example.
[Provide documentation and links for aria-live, wp.speak, etc.]
In most cases, feature plug-ins are not expected to add or modify colors in core. However, if a feature plug-in needs to add new color combinations, those combinations must meet minimum contrast requirements. Minimum contrast requirements are 4.5:1 for font sizes rendering smaller than 24px or smaller and 3.0:1 for font sizes larger than 24px or 19px and bold.
[in detailed reference, comment on why we’re referencing as pixels]
Users must be able to reach and successfully interact with all elements on the page that are actionable, including all form inputs, buttons and links by using the keyboard. They must be able to see a visual indicator of keyboard focus. You should be aware that keyboard events may operate differently when a screen reader is running.
Images and Icons
Any image resource must include an accessible name. An image can be represented by an actual element, an icon font, or an svg element; but any graphical representation is considered an image for these purposes. Different types of elements use different types of accessible names.
For <img> elements, the accessible name should be in the alt attribute. If the img is ornamental, the alt attribute should still be included, but left empty.
For icon fonts, the font icon itself should be aria-hidden, with screen-reader-text in a neighbor element. e.g.
For SVG, the SVG should be inline, so that accessible information isn’t hidden from assistive technology. SVG elements should contain aelement with the accessible name of the image. For cross-technology support, the title element should be associated with the svg element via aria-labelledby. For more information, see http://www.sitepoint.com/tips-accessible-svg/
All form inputs must include an explicitly associated <label>
Discussion of adding information about accessible content management to either the Codex or the Accessibility Handbook. Decided to add it to Handbook. Keyboard shortcuts will go in the Codex with a link from the Handbook.
#34681 Consider removing the “Disable the visual editor when writing” option.
Decided to gather user experience data. Four questions to ask:
Do you know how to switch between the visual and HTML editor in WordPress?If no, please try and figure out how, and tell us how that experience was for you.If yes, give us your thoughts about your experience using that feature.Do you use the option “Disable the visual editor when writing” in your profile?
#34625: wp-login.php site title link points to wordpress.org.
Suggested fix: removing the title attribute, changing the text to ‘Powered by WordPress’, and leaving the filter on that text.