[theme-reviewers] Updating accessibility-ready theme guidelines
Joe Dolson
design at joedolson.com
Sat Sep 20 16:57:02 UTC 2014
Attached - thanks!
Best,
Joe
On Sat, Sep 20, 2014 at 11:54 AM, Edward Caissie <edward.caissie at gmail.com>
wrote:
> @Joe - Send me the next "text". I will do the same as before and replace
> the existing.
>
> Edward Caissie
> aka Cais.
>
> On Sat, Sep 20, 2014 at 11:39 AM, Joe Dolson <design at joedolson.com> wrote:
>
>> I don't have access to edit the guidelines, but I'm certainly in favor of
>> these changes. I've updated the draft version at
>> https://make.wordpress.org/accessibility/draft-theme-review-accessibility-guidelines/
>>
>> Best,
>> Joe
>>
>> On Fri, Sep 19, 2014 at 7:31 AM, Ulrich Pogson <grapplerulrich at gmail.com>
>> wrote:
>>
>>> @Joe I was looking at the guidelines and saw that one code example could
>>> be improved for i18n. You can see the changes in the gist.
>>>
>>> Have you ever thought about internationalizing the aria-label? There is
>>> also an internationalized version is the gist.
>>>
>>> https://gist.github.com/grappler/f1e9025e00b21922f8f1
>>>
>>>
>>>
>>> On 18 September 2014 20:41, Edward Caissie <edward.caissie at gmail.com>
>>> wrote:
>>>
>>>> Glad to help.
>>>>
>>>> Edward Caissie
>>>> aka Cais.
>>>>
>>>> On Thu, Sep 18, 2014 at 1:15 PM, Joe Dolson <design at joedolson.com>
>>>> wrote:
>>>>
>>>>> Looks like what I expected. Thanks!
>>>>>
>>>>> -Joe
>>>>>
>>>>> On Thu, Sep 18, 2014 at 11:53 AM, Edward Caissie <
>>>>> edward.caissie at gmail.com> wrote:
>>>>>
>>>>>> Updated ... or at least your text has been used to replace the "make"
>>>>>> themes page. Please have a look to make sure all still looks fine.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Edward Caissie
>>>>>> aka Cais.
>>>>>>
>>>>>> On Thu, Sep 18, 2014 at 12:43 PM, Joe Dolson <design at joedolson.com>
>>>>>> wrote:
>>>>>>
>>>>>>> OK. Guidelines are updated.
>>>>>>>
>>>>>>> I've attached them as a .txt file; don't know whether attachments go
>>>>>>> through on the list, but I guess I'll find out.
>>>>>>>
>>>>>>> Note: whoever does the update, the guidelines should no longer be
>>>>>>> labeled as "draft only".
>>>>>>>
>>>>>>> Best,
>>>>>>> Joe
>>>>>>>
>>>>>>> On Thu, Sep 18, 2014 at 10:28 AM, Joe Dolson <design at joedolson.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Can't yet, but if that should change by the time I'm finished... :)
>>>>>>>>
>>>>>>>> Best,
>>>>>>>> Joe
>>>>>>>>
>>>>>>>> On Thu, Sep 18, 2014 at 10:25 AM, Emil Uzelac <emil at uzelac.me>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> If you can add, please by all means.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thursday, September 18, 2014, Joe Dolson <design at joedolson.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Well, I'll get the guidelines finalized today, one way or the
>>>>>>>>>> other, and I can send them over or add them myself then.
>>>>>>>>>>
>>>>>>>>>> Best,
>>>>>>>>>> Joe
>>>>>>>>>>
>>>>>>>>>> On Wed, Sep 17, 2014 at 7:01 PM, Edward Caissie <
>>>>>>>>>> edward.caissie at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> We can either get you the access (Otto?) as Emil suggested, or
>>>>>>>>>>> send one of us (any WPTRT admin should be fine) the text version of the
>>>>>>>>>>> final copy and we will replace the existing page's content with your new
>>>>>>>>>>> version.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Edward Caissie
>>>>>>>>>>> aka Cais.
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Sep 17, 2014 at 7:52 PM, Joe Dolson <
>>>>>>>>>>> design at joedolson.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I don't have that access. I can update the version on
>>>>>>>>>>>> make/accessibility, but nothing on themes.
>>>>>>>>>>>>
>>>>>>>>>>>> My understanding was that we wanted the review guidelines to
>>>>>>>>>>>> stay packaged, rather than sending people of you external documents.
>>>>>>>>>>>>
>>>>>>>>>>>> I do intend to make one final pass through the doc before
>>>>>>>>>>>> posting it; turning examples into theme code.
>>>>>>>>>>>>
>>>>>>>>>>>> Best,
>>>>>>>>>>>> Joe
>>>>>>>>>>>> On Sep 17, 2014 6:47 PM, "Emil Uzelac" <emil at uzelac.me> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> You should be able to do this with your own credentials, if
>>>>>>>>>>>>> not we can ask Otto to help us out.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wednesday, September 17, 2014, Edward Caissie <
>>>>>>>>>>>>> edward.caissie at gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Are we talking about duplicating the content? Might it be
>>>>>>>>>>>>>> better to link to the a11y page(s) instead?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If we want to duplicate the content, I can copy and paste a
>>>>>>>>>>>>>> "text" version of the content from
>>>>>>>>>>>>>> http://make.wordpress.org/accessibility/draft-updated-theme-review-accessibility-guidelines/
>>>>>>>>>>>>>> updating the title to match.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Edward Caissie
>>>>>>>>>>>>>> aka Cais.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Sep 17, 2014 at 6:13 PM, Joe Dolson <
>>>>>>>>>>>>>> design at joedolson.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Who do I need to talk to to get the accessibility-ready
>>>>>>>>>>>>>>> guidelines updated to the newer version?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://make.wordpress.org/themes/guidelines/guidelines-accessibility/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://make.wordpress.org/accessibility/draft-updated-theme-review-accessibility-guidelines/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> ==================
>>>>>>>>>>>>>>> Joseph Dolson
>>>>>>>>>>>>>>> Accessibility consultant & WordPress developer
>>>>>>>>>>>>>>> http://www.joedolson.com
>>>>>>>>>>>>>>> http://profiles.wordpress.org/joedolson
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> theme-reviewers mailing list
>>>>>>>>>>>>>>> theme-reviewers at lists.wordpress.org
>>>>>>>>>>>>>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> theme-reviewers mailing list
>>>>>>>>>>>>> theme-reviewers at lists.wordpress.org
>>>>>>>>>>>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> theme-reviewers mailing list
>>>>>>>>>>>> theme-reviewers at lists.wordpress.org
>>>>>>>>>>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> theme-reviewers mailing list
>>>>>>>>>>> theme-reviewers at lists.wordpress.org
>>>>>>>>>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> ==================
>>>>>>>>>> Joseph Dolson
>>>>>>>>>> Accessibility consultant & WordPress developer
>>>>>>>>>> http://www.joedolson.com
>>>>>>>>>> http://profiles.wordpress.org/joedolson
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> theme-reviewers mailing list
>>>>>>>>> theme-reviewers at lists.wordpress.org
>>>>>>>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> ==================
>>>>>>>> Joseph Dolson
>>>>>>>> Accessibility consultant & WordPress developer
>>>>>>>> http://www.joedolson.com
>>>>>>>> http://profiles.wordpress.org/joedolson
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> ==================
>>>>>>> Joseph Dolson
>>>>>>> Accessibility consultant & WordPress developer
>>>>>>> http://www.joedolson.com
>>>>>>> http://profiles.wordpress.org/joedolson
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> theme-reviewers mailing list
>>>>>>> theme-reviewers at lists.wordpress.org
>>>>>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> theme-reviewers mailing list
>>>>>> theme-reviewers at lists.wordpress.org
>>>>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ==================
>>>>> Joseph Dolson
>>>>> Accessibility consultant & WordPress developer
>>>>> http://www.joedolson.com
>>>>> http://profiles.wordpress.org/joedolson
>>>>>
>>>>> _______________________________________________
>>>>> theme-reviewers mailing list
>>>>> theme-reviewers at lists.wordpress.org
>>>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> theme-reviewers mailing list
>>>> theme-reviewers at lists.wordpress.org
>>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>>
>>>>
>>>
>>> _______________________________________________
>>> theme-reviewers mailing list
>>> theme-reviewers at lists.wordpress.org
>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>
>>>
>>
>>
>> --
>> ==================
>> Joseph Dolson
>> Accessibility consultant & WordPress developer
>> http://www.joedolson.com
>> http://profiles.wordpress.org/joedolson
>>
>> _______________________________________________
>> theme-reviewers mailing list
>> theme-reviewers at lists.wordpress.org
>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>
>>
>
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>
>
--
==================
Joseph Dolson
Accessibility consultant & WordPress developer
http://www.joedolson.com
http://profiles.wordpress.org/joedolson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20140920/6a455a43/attachment-0001.html>
-------------- next part --------------
The Theme Accessibility Audit is an optional stage of the theme review process. Submitted themes (or theme updates) that use the tag <code>accessibility-ready</code> must undergo an accessibility review to check against these guidelines.
If the theme does not pass the accessibility audit, the theme must either be updated to meet the accessibility guidelines or to remove the tag. Themes with the <code>accessibility-ready</code> tag may not be made live in the theme repository until they have passed the accessibility review.
Theme developers are encouraged to exceed these requirements; they are the minimum requirements for the <code>accessibility-ready</code> tag.
Themes that fail the accessibility review can still be approved for addition to the Theme Repository, but must remove the <code>accessibility-ready</code> tag. Themes that go live without being reviewed will be given 72 hours to either begin the process to rectify accessibility issues or to update without the <code>accessibility-ready</code> tag or they will be suspended.
<h3>Required:</h3>
<strong>Headings</strong>
Theme templates should use a reasonable HTML heading structure — including the use of heading elements for page sub-sections. Heading markup must NOT be used for presentational purposes. Heading elements for structure MAY be positioned off-screen as long as this is not at the expense of providing good, visual, structure.
Specifically, sub-sections defined by your theme MUST use heading elements. This includes wrapping your post title in a heading when used in an article context and wrapping widget titles in headings.
See <a href="http://webaim.org/techniques/semanticstructure/">Semantic Structure from WebAIM</a> for more information about heading structure.
<strong>Link Text</strong>
Links MUST avoid repetitive non-contextual text strings such as ‘read more…’ and should also also make sense when taken out of context. Bare urls must NOT be used as links. Context-specific text MAY be positioned off-screen.
The core-defined ‘read more’ links fall under this guideline. You can use filters to replace these links. The post title should generally be used in addition to the normal directive text.
<strong>Example:</strong>
<ul>
<li>Fails:
<pre>
<code>
the_content(
__( 'Continue reading', 'textdomain' )
);
</code>
</pre>
</li>
<li>Passes:
<pre>
<code>
the_content(
sprintf(
__( 'Continue reading%s', 'textdomain' ),
'<span class="screen-reader-text"> '.get_the_title().'</span>'
)
);
</code>
</pre>
</li>
</ul>
<h3>Controls</h3>
All theme features that behave as buttons or links must use <code><button></code>, <code><input></code>, or <code><a></code> elements, to ensure native keyboard accessibility and interaction with screen reader accessibility APIs.
All controls must also have machine-readable text to indicate the nature of the control.
<strong>Example:</strong>
<ul>
<li>Fails: <code><span class="menu-toggle"><span class='dashicons dashicons-menu'></span></span></code></li>
<li>Passes: <code><button class="menu-toggle"><span class="dashicons dashicons-menu"></span><span class="screen-reader-text">Menu</span></button></code></li>
<li>Better: <code><button class="menu-toggle"><span class="dashicons dashicons-menu"></span>Menu</button></code></li>
</ul>
See <a href="http://www.karlgroves.com/2013/05/14/links-are-not-buttons-neither-are-divs-and-spans/">Links are not buttons; neither are <code>div</code>s and <code>span</code>s</a> for detailed information.
<h3>Keyboard Navigation</h3>
Theme authors MUST provide visual keyboard focus highlighting in navigation menus and for form fields, submit buttons and text links. Navigation by keyboard should also be intuitive and effective.
<strong>Example:</strong>
<ul>
<li>Fails: Dropdown navigation menus are hidden using <code>display:none;</code> and brought into view on <code>:hover</code></li>
<li>Passes: Dropdown navigation menus are hidden using <code>position: absolute;</code> and brought into view on <code>:hover</code> and <code>:focus</code>, and are navigable using the <code>tab</code> key</li>
<li>Better: Dropdown navigation menus are hidden using position: absolute; and brought into view on <code>:hover</code>, <code>:focus</code>, and are navigable using either the <code>tab</code> key or by using the keyboard arrow keys.</li>
</ul>
<h3>Contrasts</h3>
Theme authors MUST ensure that all background/foreground color contrasts for plain content text are within the level AA contrast ratio (4.5:1) specified in the Web Content Accessibility Guidelines (WCAG) 2.0 for color luminosity.
Background/foreground color contrast also applies to change of state (:focus or :hover) if there is no additional indicator of :focus or :hover, such as a text decoration change.
The default settings will be the only color scheme checked. If a theme offers multiple color schemes, only the default scheme is required to pass these guidelines. Alternative themes should be clearly labeled if they do not meet accessibility guidelines.
There are many tools for testing color contrast:
<strong>Web:</strong>
<ul>
<li><a href="https://www.joedolson.com/tools/color-contrast-compare.php">Contrast Comparison</a></li>
<li><a href="http://contrast-finder.tanaguru.com/">Contrast Finder</a></li>
</ul>
<strong>Firefox Add-ons:</strong>
<ul>
<li><a href="https://addons.mozilla.org/en-US/firefox/addon/tanaguru-contrast-finder/">Contrast Finder</a></li>
<li><a href="https://addons.mozilla.org/en-US/firefox/addon/juicy-studio-accessibility-too/?src=ss">Accessibility Toolbar</a></li>
</ul>
<strong>Chrome Add-ons:</strong>
<ul>
<li><a href="https://chrome.google.com/webstore/detail/color-contrast-analyzer/dagdlcijhfbmgkjokkjicnnfimlebcll?hl=en">Color Contrast Analyzer</a></li>
<li><a href="https://chrome.google.com/webstore/detail/nocoffee/jjeeggmbnhckmgdhmgdckeigabjfbddl?hl=en">NoCoffee</a></li>
</ul>
<h3>Skip Links</h3>
Themes MUST include a mechanism that enables users to navigate directly to content or navigation on entering any given page. These links MAY be positioned off screen initially but MUST be available to screen reader users and MUST be visible on focus for sighted keyboard navigators.
A minimally conforming skip link MUST:
<ul>
<li>Be the first focusable element perceived by a user via screen reader or keyboard navigation.</li>
<li>Be visible when keyboard focus moves to the link.</li>
<li>Move focus to the main content area of the page when activated.</li>
</ul>
There is an outstanding bug in WebKit-based browsers that prevents focus being moved to elements that aren't natively focusable. You can either enqueue JS to patch this bug or assign tabindex=-1 to your main content region to handle this issue.
<h3>Forms</h3>
Comment forms MUST have appropriate field labels and all content within form tags MUST be explicitly associated to a form control. Post-submission responses (errors or confirmations) MUST be perceivable. If you are using the default WordPress comment or search forms, these pass the accessibility-ready criteria.
Forms that include a single input (such as a standard search form) may, optionally, position the input label offscreen. Themes that incorporate non-standard forms (e.g. a contact form) will be audited using the same criteria.
If you are replacing the default WordPress forms or form behavior (such as to handle responses with AJAX), you MUST:
<ul>
<li>Use form controls that have explicitly associated <code><label></code> elements.</li>
<li>Create feedback mechanisms (such as via AJAX) that expose responses to screen readers. Look at techniques with ARIA for further information.</li>
</ul>
See <a href="http://heydonworks.com/practical_aria_examples/">Practical ARIA Examples</a> for a variety of examples demonstrating how to use ARIA in scripted interfaces.
<strong>Example:</strong>
<ul>
<li>Fails:
<pre>
<code>
<input type='text' name='s' value='<?php echo trim( get_search_query() ); ?>'>
</code>
</pre>
</li>
<li>Passes: (label is hidden)
<pre>
<code>
<label for='s' class='screen-reader-text'><?php _e( 'Search', 'textdomain' ); ?></label>
<input type='text' name='s' id='s' value='<?php echo trim( get_search_query() ); ?>'>
</code>
</pre>
</li>
<li>Better: (label is visible)
<pre>
<code>
<label for='s'><?php _e( 'Search', 'textdomain' ); ?></label>
<input type='text' name='s' id='s' value='<?php echo trim( get_search_query() ); ?>'>
</code>
</pre>
</li>
</ul>
<h3>Images</h3>
Decorative images MUST be included using CSS. Where theme authors add images to template markup or provide a method for end users to add images, theme authors MUST incorporate an appropriate alt attribute or the means for an end user to provide one. During the audit, the <a href="http://dev.w3.org/html5/alt-techniques/#tree">W3C alt text decision tree</a> is used to determine whether images are using the alt attribute appropriately.
<strong>Example:</strong>
<ul>
<li><strong>Featured Images:</strong> The alt attribute for featured images is defined in the media manager. In any case where a featured image is displayed, the alt attribute must be included with the image.</li>
<li><strong>Icons and icon fonts:</strong> if the icon is <strong>representing text</strong> (e.g., there is no visible text), the icon must include fallback text for screen readers that indicates what the icon means. If the icon is <strong>supplementing text</strong> (e.g., it appears with text that indicates function or purpose), then the icon should not include fallback text, and should be hidden from screen readers using <code>aria-hidden</code>.</li>
</ul>
<h3>Media</h3>
Media resources must NOT auto start or change without user action as a default configuration. This includes resources such as audio, video, or image/content sliders and carousels.
In general, media resources of this nature are likely to fall under the <a href="https://make.wordpress.org/themes/guidelines/guidelines-plugin-territory/">plugin territory guidelines</a>, and will not be allowed in your theme. If you have a conforming usage, however, these rules will apply.
<h3>Not Allowed</h3>
Inclusion of any of the following is NOT allowed:
<ul>
<li>Any positive tabindex attribute. Negative or zero value tabindex is allowed in specific circumstances (assessed on a case-by-case basis).</li>
<li>The inclusion of the accesskey attribute.</li>
<li>Spawning new windows or tabs without warning the user.</li>
</ul>
<h2>Recommended:</h2>
<h3>ARIA Landmark Roles</h3>
Assign landmark roles to the main content areas of your site to enable landmark based scanning for screen readers. All content on your site must be wrapped in at least one landmark role if you use these roles. Whie using ARIA roles is optional, if they are used they must be used correctly.
Appropriate usage of roles:
<ul>
<li><code>role="banner"</code> == header</li>
<li><code>role="main"</code> == main content</li>
<li><code>role="complementary"</code> = sidebars</li>
<li><code>role="content-info"</code> = footer</li>
<li><code>role="search"</code> = search form</li>
<li><code>role="navigation"</code> = navigation menus</li>
</ul>
If a particular role appears more than once on a page, you should provide an ARIA label for that role:
<pre>
<code>
<nav role="navigation" aria-label="<?php _e( 'Primary Navigation', 'textdomain' ); ?>">
<nav role="navigation" aria-label="<?php _e( 'Secondary Navigation', 'textdomain' ); ?>">
</code>
</pre>
<h3>Zoomable Text</h3>
If a user zooms with text-only zoom enabled or has changed the base font-size in their browser, the site should support this without breaking the theme by creating overlapping or hidden text.
<h3>Removal of <code>title</code> attributes</h3>
While the <code>title</code> attribute is occasionally of value, it is never of value if the attribute's text is the same as the visible text. This is a common issue with post titles and permalinks. Remove extraneous <code>title</code> attributes.
More information about the theme-reviewers
mailing list