Want to participate in reviewing WordPress themes for the accessibility-ready tag? There’s a trac keyword for that! Themes awaiting an accessibility-ready review.
Updates from Joe Dolson Toggle Comment Threads | Keyboard Shortcuts
I’ve created all new tickets for each file referenced from the original remove title attributes trac ticket (http://core.trac.wordpress.org/ticket/24766). I originally split it up into 17 separate tickets, but closed 3 of them already, because they had already been committed into 3.8 or earlier.
I’ve added comments and/or patches, as relevant, on all of the remaining tickets – so please chime in with opinions as relevant! Many of these incorporate situations where a 2nd opinion would be valuable, because the title attribute incorporates relevant information and some alternative handling may be necessary.
http://core.trac.wordpress.org/ticket/26549 – 2nd opinion
http://core.trac.wordpress.org/ticket/26550 – 2nd opinion
http://core.trac.wordpress.org/ticket/26551 – 2nd opinion
http://core.trac.wordpress.org/ticket/26552 – 2nd opinion
http://core.trac.wordpress.org/ticket/26553 – 2nd opinion
http://core.trac.wordpress.org/ticket/26555 – 2nd opinion
http://core.trac.wordpress.org/ticket/26558 – 2nd opinion
Potentially useful accessibility plug-in I learned about today at WordCamp Chicago: http://wordpress.org/plugins/media-ally/
Just submitted: http://core.trac.wordpress.org/ticket/24148. Comments welcome.
I’ve updated the Theme Review guidelines for Accessibility again. This update takes into a consideration a number of suggestions and questions from Chip Bennett regarding the understanding of issues and how to resolve them.
Among the changes:
- Images now state that decorative images must be included with CSS.
- Headings explicitly states that post and widget titles must be wrapped in headings, to draw the ‘reasonable headings’ guidelines into a context explicitly relevant to WordPress structure as defined by a theme.
- Link text provides specific techniques for accomplishing the goal.
- Keyboard navigation provides guidance on testing and specific mention of one of the most common failures for dropdown menus.
- Contrast references tools for testing.
- Skip links defines a conforming skip link.
- Forms defines specific changes that can be made to defaults that would break accessibility.
Your comments are welcome.
I’ve been chatting with Chip Bennett via the Theme Review list about the Theme Audit guidelines. With his feedback (which was from the theme author and reviewer perspective, and very valuable) and the feedback from the comments on my previous post, I’ll be working on the next version with a variety of changes of various types. He’s going to be proposing some changes to the general guidelines that will obviate the need for a couple of the elements in the accessibility audit guidelines.
joe and I’ve been chatting with Chip Bennett via the… - 뉴스 are discussing. Toggle Comments
Hey, all. I’ve updated the theme auditing guidelines and they have now been added to the theme reviewer’s documentation. Take a look at the requirements for the #accessibility-ready theme tag and comment back here with any suggestions or changes.
Note that these guidelines are in addition to the rest of the theme guidelines, and there are many quality guidelines already established that don’t need to be part of the accessibility audit.
If anybody has a chance to take a look at the progress on autosave and post locking that would be valuable – I have some concerns about whether the context changes when sessions have expired will be announced, but haven’t had time to test it at all. Ticket 23295
Per the most recent conversations about the accessibility-ready tag for the theme repository, I’ve been working on establishing some new classes for the Theme Check plug-in that can scan themes for accessibility issues.
Because accessibility is not easily verified, particularly when you’re not working in an HTML context, most of these are relatively generalized, and work on the principle that I want to avoid false positives (accessibility issues detected that don’t actually exist), but am perfectly comfortable with false negatives. The reason for this is that these are only intended to be indicative flags; they aren’t intended to substitute for an actual reviewer going over the themes and judging it according to the theme accessibility audit guidelines.
The idea is that any definite failures we can identify before engaging in a hands-on review are beneficial — and because theme authors have access to the Theme Check plug-in and can scan for these issues themselves, and learn of them before they submit.
I’ve prepared six classes to extend the Theme Check plug-in, but they could all stand a review (and some creativity in reviewing other areas, if you’re comfortable enough with PHP).
You can download my modified version of the Theme Check plug-in (six new files, one edited: new files in /checks/, prefixed with
a11y; edited file is just the stylesheet, to add a color for the class
Experiment with it, change it, let me know.
Some of these are very superficial or crude checks; but if you have an idea how to improve them, share your wisdom! Keep in mind that all of these tests are performed on un-rendered code; so using a DOM parsing engine is not an option — we can use standard testing methods when it comes to reviewing the ultimate output of the theme.
Any use of
accesskey is a failure, so this class returns an error if any occurrence of the string ‘accesskey’ occurs anywhere in any theme PHP file.
Examines each PHP file individually. If any file contains
select elements without also containing a
label element, returns an error. This is superficial, as it doesn’t currently verify that there is any equivalency between inputs and labels, and doesn’t specifically exclude hidden inputs as an acceptable case.
Examines each PHP file individually. If any file contains the string ‘<img’ but does not contain the string ‘alt=’ it returns an error. It’s crude, and this could definitely be improved.
Examines each PHP file individually. Runs a regex to identify link text, returns errors for any link with no content. However, the actually cases within a theme are so diverse that there are *many* circumstances that this won’t pick up using the current rules, including link texts consisting only of white space characters, linked images with no alt attributes, or complex PHP concatenations.
Just like the
accesskey check. However, there are allowable cases for use of tabindex, and this class does not account for those at the moment.
Scans the PHP files for occurrences of the strings ‘<h1′ and ‘<h2′. All it’s verifying is the presence of structural headings. If no structural headings are found anywhere in the code, it returns an error indicating a lack of HTML heading structure. Also very crude, but it will pick up the worst-case scenario.
Just updated the WP Accessibility plug-in page to provide extensive information about what problems the plug-in solves and why. I also included links to important relevant documents on each item.