Per the most recent conversations about the accessibility 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)-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 HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. 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 PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.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.