Support Requests
If you post a comment here looking for support regarding your own site, it will be deleted. If you need support, please post on the wordpress.org support forums.
Thank you.
Recent Updates Toggle Comment Threads | Keyboard Shortcuts
-
esmi
-
Joseph Karr O'Connor
IRC Meeting: October 9, 2013
We discussed accessibility progress made by @grahamarmfield, @rianrietveld, Bram Duvigneau and others at WordCamp Europe. Rian wrote something about it: http://blog.rrwd.nl/2013/10/09/wordcamp-europe-2013-lessons-learned/
@joedolson and @sabreuse continue to help with the Twenty Fourteen theme.
We discussed communications channels: Twitter account @WPAccessibility, Make WordPress Accessible for public discussions of the group, an email list for prep work, the WordPress Accessible LinkedIn group for public discussions for everyone, and IRC discussions for working meetings. Also discussed was the possibility of creating a Facebook page which the group decided against doing.
@rianrietveld and @atimmer discussed setting up a testing environment and will continue that discussion offline.
-
Joseph Karr O'Connor
IRC Meeting: October 2, 2013
The team discussed active tickets including http://core.trac.wordpress.org/ticket/25054 3.8, sabreuse->(no owner), new, Twenty Fourteen Accessibility fixes.
A list of accessibility tickets: http://bit.ly/1glL1bH
A team member has set up an accessibility test server pulling the updates for team use.
-
Rian Rietveld
Hi, I’m not sure of this has been discussed before, but I saw the vote on the new MP6 theme. http://polldaddy.com/poll/7437854/. Has a colour scheme with sufficient contrast been suggested already? Maybe not for the default theme, but as a choice? In all of this themes the grey in the input fields is very light, did someone do some calculations on this?
-
Graham Armfield
-
_Redd
Color comparisons continue to above:
Pixel #59524c from color picker, #fff for text:
Results: Results for Luminosity Contrast Ratio
The contrast ratio is: 7.68:1
Passed at Level AAA: The luminosity contrast ratio is very good for the chosen colours (#59524c and #fff).
Ectoplasm #523f6d #fff for text
Results:
Results for Luminosity Contrast Ratio
The contrast ratio is: 9.17:1
Passed at Level AAA: The luminosity contrast ratio is very good for the chosen colours (#523f6d and #fff).
…..more comparisons to follow
-
_Redd
Comparisons continue to above:
Sunrise #cf4944 as background #fff for text
Results for Luminosity Contrast Ratio
The contrast ratio is: 4.48:1
Passed at Level AA for large text only: If the text is large text (at least 18 point or 14 point bold), the luminosity contrast ratio is sufficient for the chosen colours (#cf4944 and #fff).
Vineyard #462b36 as background #fff for text
Results: Results for Luminosity Contrast Ratio
The contrast ratio is: 12.66:1
Passed at Level AAA: The luminosity contrast ratio is very good for the chosen colours (#462b36 and #fff).
…more coming
-
_Redd
Color contrast evaluation continues:
Primary #35395c as background, #fff as foreground (text)
Results for Luminosity Contrast Ratio
The contrast ratio is: 11.10:1
Passed at Level AAA: The luminosity contrast ratio is very good for the chosen colours (#35395c and #fff).
…summary to follow
-
_Redd
Hi, Rian, I’m not sure my first entry got saved. To repeat from earlier first reply, I really LOVE the new MP6 theme, but also very happy to have some one ask for a check on color contrast.
Below is repeating what I said in an earlier reply, so accept my apologies if the earlier reply shows up again.
In an attempt to roughly gauge success criteria for W3C color contrast standards, I used Snag-It to capture an image, and then used Photoshop eyedropper to at least grab an approximation of the color, as I was unable to actually see CSS code for the exact colors.
I then used Juicy Studio’s Color Contrast Analyzer to get a sense of color contrast among the options.
Blue: Photoshop color picker for the background: #52accc Using White Foreground #fff (for the text)
Results: Results for Luminosity Contrast RatioThe contrast ratio is: 2.58:1
Fail: The luminosity contrast ratio is insufficient for the chosen colours (#52accc and #fff) (Needs large text to pass)
Seaweed #15757a from color picker, #fff for text:
Results for Luminosity Contrast Ratio
The contrast ratio is: 5.44:1
Passed at Level AA for regular text, and pass at Level AAA for large text: If the text is large text (at least 18 point or 14 point bold), the luminosity contrast ratio is sufficient for the chosen colours at Level AAA; otherwise, Level AA (#15757a and #fff).
In short summary, the blue, although extremely attractive, does not provide sufficient color contrast to meet W3C guidelines for contrast. The seaweed and sunrise colors will pass if the text is large, and the rest are fine.
Thank you so much for asking.
-
Rian Rietveld
Hi _Redd, Thanks for checking. I love the new themes too! way better than it was.
-
-
esmi
I think the point to keep in mind here is that these would be user-selectable schemes (as I understand it), So as long as the default scheme passes minimum WCAG contrast levels, it really doesn’t matter what contrasts are present in the alternative schemes. Also, remember some dyslexics would welcome a very low contrast scheme.
I’ve actually suggested that the color schemes shipped with the plugin (and later in core) include at least one high-contrast scheme for visually-impaired user and one very low contrast scheme for some dyslexics. This ability to provide schemes for different user groups is something that Helen & I have talked about (albeit rather wistfully) in the past.
-
Joe Dolson
Jinx!
-
-
Joe Dolson
I think it’s important to note that these are not all of the themes; the primary MP6 theme, which David Kennedy has been reviewing, will definitely be included when MP6 is shipped; these other options are candidates as additional color schemes that will be available.
Esmi has already suggested adding a high-contrast and a low-contrast color scheme to accommodate for low vision or dyslexic needs; voices might be helpful there: http://make.wordpress.org/ui/2013/10/01/mp6-color-schemes/
-
Rian Rietveld
Thanks all for the quick response. It would be perfect if MP6 will be included with a few accessible colour schemes. @esmi, thanks for all your effort!
-
-
Joseph Karr O'Connor
Most of the time was spent discussing http://core.trac.wordpress.org/ticket/21334 3.7, grahamarmfield->helen, closed, Row actions are not always keyboard accessible. Helen Hou joined us for the discussion.
1. When mouse hovers over a page/post row in main Pages/Posts screen ‘quick links’ appear. Suggesting that they also are made available for keyboard-only users and screen reader users.
2. When using the QuickEdit panel the time/date controls have separate tabindex and no labels. Suggesting that the tabindex be removed from those controls, and that labels be used.
Discussion centered around the need to reduce verbosity for screen reader users, while still making the controls available to them.
It was decided to test the latest build and come back with a recommendation.
-
Graham Armfield
I’ve tested the fix with the latest (I believe) version of NVDA and the quick links become accessible when focus is on the Post/Page Title. So that’s good. They are also not all listed by screen readers when the Posts/Pages list first appears.
-
-
Helen Hou-Sandi
Feedback on #21334: Row actions are not always keyboard accessible
I’ve made two commits so far to address the fact that row actions (that is, edit/quick edit/trash under each post’s title) only show on hover. I have two questions regarding this that I could your expertise on:
1. In terms of CSS, this is controlled by the visibility property. My understanding has been that visibility: hidden does not get read by screen readers. If this is the case, then we may want to use an alternative method for show/hide. Are these row actions currently in a state where they are useful to screen readers or are they better off not being read (for now)?
2. Right now the keyboard tabbing will only trigger them to show when in the same cell. Should this expand to whenever focus is within the row? I believe visually it is when hovering on the table row.Thanks!
-
PhilippeVay
Hi,
both display: none; and visibility: hidden; aren’t read by screen readers, that’s correct. There are now other CSS techniques that will also hide content but not on all screen readers (ex: height: 0).
The well-named WP class .visually-hidden will move content off viewport so it’s still read by screen readers but not visible to sighted users with CSS activated: it’d be a good alternative to hide content only to sighted users.
Useful or not here? I haven’t been active on WP for a while so I’ll have to take a look to these actions first Concerning keyboard and hiding content: I think there are 3 categories of disabled people that have different needs and habits.
- blind people will use keyboard and a screen reader,
- low vision people may use mouse and/or keyboard and a screen reader or not. The four combinations are possible
- motor impaired will probably use a keyboard but no screen reader
Screen reader may access rich information in an accessible table (related to header cells of a particular cell via scope – or id/headers – attributes) even if a link or button is off viewport while motor impaired wouldn’t be able to interact with this same table. So I think it’d be better to show all actions in the current row if one of the links has taken focus.
-
Joe Dolson
I generally agree with Philippe.
Keyboard tabbing should trigger the links, I think, whenever focus is in the row; that will maximize awareness of these options. It’s not critically necessary, but when it comes to being able to find and understand the options, this will be the better solution.
For screen readers, just using the visually-hidden solution, so that the links are always available for screen reader users is, in my opinion, the best solution. It does run into the repetitive-link problem, but I honestly think that in this user interface that’s not really an issue; it will be more valuable to be able to have those links available in context.
-
Helen Hou-Sandi
Thanks so much for the quick feedback – based on the IRC chat, it seems that the solution that is in the current nightly might actually be for the best, due to lack of context for screen readers and the sheer number of links that would appear. Perhaps things can be improved in the future for screen readers in this regard, although these links are convenience and not exclusive to the area. For 3.7, let’s focus on getting it just right for keyboard tabbing. We actually need to get this done in the next couple days, so I look forward to any further feedback, but do note that there’s a chance that further improvements will have to wait until 3.8 if this drags on.
-
_Redd
Hi Helen, from what I can tell from running a very brief test, the quick links menu is available upon the first visit to the post, and it allows you to get into the quick edit menu and perform edits, but once that takes place, the quick edit menu disappears and is no longer available to a screen reader (at least NVDA).
Would you like access to my test site?
-
_Redd
I’m sorry, Helen, I forgot to include an example of what I’m talking about. Here is the link to the site.
Once again, we are all really appreciative of what you’re doing for us. You are the BEST!
-
-
Joseph Karr O'Connor
IRC Meeting: September 18, 2013
Cynthia Waddell
Accessibility Statement Final Draft
“Accessibility is the degree to which a product, device, service, or environment is available to as many people as possible.” Cynthia Waddell
WordPress is founded on the principles of an inclusive community and democratization of publishing. The development of WordPress, based on standards and best practices, offers a constantly improving environment with flexibility and choice. We promise to always work toward creating an environment accessible to as many people as possible, inclusive of technology and ability.
We want community involvement and welcome feedback. Your comments help us enhance the accessibility of WordPress.
Resources
End Accessibility Statement
Projects To Be Followed
During the remainder of the meeting we discussed the projects we believe should be followed by the WordPress Accessibility Team. We agreed that we have too few people on the team to follow all these projects, but we compiled the following list.
-
Joseph Karr O'Connor
IRC Meeting: September 11, 2013
We edited an accessibility statement.
At the head of the statement is a quote by Cynthia Waddell: “Accessibility is the degree to which a product, device, service, or environment is available to as many people as possible.”
[Then comes the statement:]
WordPress is founded on the principles of an inclusive community and democratization of publishing. The development of WordPress, based on standards and best practices, offers a constantly improving environment with flexibility and choice. We promise to always work toward creating an environment accessible to as many people as possible, inclusive of technology and ability.
[The statement is followed by resources and contact information.]
Resources are available if you would like to learn more about WordPress accessibility.
- Make WordPress Accessible
- WordPress Codex: Accessibility (NB: Codex being retired)
- [WordPress Handbooks] (links to all handbooks)
- [Other links]
We want community involvement and welcome feedback. Your comments help us enhance the accessibility of WordPress.
[Contact us here, and here, etc.]
-
Jen Mylo
Very minor note, would say “democratization of publishing,” rather than “democratization of the web,” to stay consistent with messaging elsewhere.
-
Joseph Karr O'Connor
Thanks! Made change.
-
Joseph Karr O'Connor
IRC Meeting: September 4, 2013
Yesterday’s meeting focused almost entirely on developing a global accessibility statement for WordPress. It was decided that the statement should be broad in nature, and that it will generally support accessibility with links to more specific information that this group maintains.
The voluntary accessibility theme check process was mentioned, that process is nearly ready to launch.
Much thanks to Mel Pedley @esmi for her guidance and leadership as team representative for the past 18 months. I will now serve as team representative.
You can also contact us with words of encouragement or feedback on Twitter @WPAccessibility.
-
Amy Hendrix (sabreuse)
So many thanks to @esmi for all the work repping this group! And congrats/welcome aboard, Joe!
-
_Redd
Congratulations to Joe! I know we will all benefit from your presence here, as so many have already benefited from your other contributions to WordPress, such as your amazing Cities Themes project. And, I don’t have words strong enough or big enough to thank @esmi for her presence in the Accessibility blog. I think she was the first person I “met” in this group, and probably the one who figured most prominently in my education for accessibility in WordPress. She’s done more good than she knows. I have many times called attention to her input on these blogs and in the forums to others, and the guidance she provided, in turn, has impacted many websites for the better. Mel, we all can’t thank you enough.
-
-
esmi
IRC Meeting: August 28, 2013
The main focus of the meeting ( and the group) was still on one of our primary objectives — the development of a global accessibility statement for WordPress. After reviewing Drupal’s accessibility statement again, it was decided to begin work on drafting our own statement that can then be presented to the wider community for discussion.
-
esmi
Title Attributes Galore
The patches for Trac ticket 24766 are slated for addition to WordPress 3.7. This is great news for assistive technology users who have been forced to wade through a sea of unnecessary title attribute verbiage. But we need to ensue that the patches cover all unnecessary title attributes and that those deliberately excluded from the patches do not present any accessibility issues.
Currently, the excluded methods, functions and scripts are:
the_author_posts_link()- rss.php
wp_fullscreen_html()get_adjacent_post_rel_link()_walk_bookmarks()get_image_tag()the_shortlink()
-
David A. Kennedy
I’m wondering if we missed any? I believe some functions, like
get_the category_listand
edit_post_linkhave title tags built in as well. I’m not as familiar with core so looking through the diff makes it hard to tell. Commenting here to get opinions and not junk up the ticket.
-
Amy Hendrix (sabreuse)
Both of those functions are included in the patch that’s currently on the ticket — you can see the full list at the ticket link.
The list in this post is just the ones that I left off the patch, either because they’re deprecated functions (which means aren’t actually used in core anywhere, and we normally wouldn’t make any changes to them unless it was for something like security), or because the title attributes are being used for help and not just labels (and in that case, they should get a better solution rather than just being deleted without any kind of fallback).
It’s definitely not a problem to get this batch in, and still pick up any that were missed in subsequent patches.
-
esmi
Understood, But my concern is how to handle wp_fullscreen_html()
-
Amy Hendrix (sabreuse)
Yep, got that — I was just trying to answer David’s question about other functions that didn’t appear in this post.
On with the wp_fullscreen_html() discussion, which is definitely a tougher case than most of these!
-
-
-
-
Joe Dolson
I think we need to consider some alternatives for the wp_fullscreen_html labels and interface generally — this is definitely not a simple case of removing the title attributes alone. It should probably be pushed as a separate ticket; it’s related, but it seems sufficiently different that treating it independently is worth while. Thoughts on that?
-
esmi
I agree. This needs to be treated as a separate ticket.
-
-
Joe Dolson
So, went to work on this to create the ticket, and decided that I first needed to create a ticket on keyboard focus — there are a lot of problems with keyboard focus in the full screen editor, so it’s nearly impossible to use with a keyboard. Ticket 25111.
A very good point Rian.