[theme-reviewers] TRT Handbook Update

Joe Dolson design at joedolson.com
Wed Sep 24 19:43:44 UTC 2014 

It looks like the accessibility theme review guidelines in the Handbook are
the old guidelines; they should be updated to the version updated last
week. (Attached)

Best,
Joe

On Wed, Sep 24, 2014 at 12:25 PM, Emil Uzelac <emil at uzelac.me> wrote:

> All I did was the link updates on http://codex.wordpress.org/Theme_Review and
> from there all looks good.
> The rest will need to be combed down :)
>
> On Wed, Sep 24, 2014 at 7:37 AM, Jose Castaneda <jomcastaneda at gmail.com>
> wrote:
>
>> I thought we did as well?
>>
>> On Wed, Sep 24, 2014 at 5:36 AM, Edward Caissie <edward.caissie at gmail.com
>> > wrote:
>>
>>> Didn't we change the screenshot maximum size to 880 x 660?
>>>
>>>
>>> Edward Caissie
>>> aka Cais.
>>>
>>> On Wed, Sep 24, 2014 at 3:56 AM, Venkat Raj <venkat at webulous.in> wrote:
>>>
>>>>  @Emil, Actually need to remove "guidelines-" from URLs from Required #
>>>> section.
>>>>
>>>> I mean,
>>>> Correct Link:
>>>> https://make.wordpress.org/themes/handbook/guidelines/theme-check/
>>>>
>>>> Wrong Link:
>>>> https://make.wordpress.org/themes/guidelines/guidelines-theme-check/
>>>>
>>>> PS: Am i replying correctly this time? Was only receiving Digest
>>>> previous times.
>>>>
>>>>
>>>> On Wednesday 24 September 2014 10:06 AM, Emil Uzelac wrote:
>>>>
>>>> Thanks, I'll update
>>>>
>>>> On Tuesday, September 23, 2014, Sakin Shrestha <info at sakinshrestha.com>
>>>> wrote:
>>>>
>>>>>   Hi Emil,
>>>>>
>>>>>  It looks really nice and thank you all.
>>>>>
>>>>>  I found issue with links in this page
>>>>> https://make.wordpress.org/themes/handbook/guidelines/#required . All
>>>>> the guidelines are linked to old URL and it is showing Page Not found.
>>>>>
>>>>>  Regards,
>>>>> Sakin
>>>>>
>>>>> On Wed, Sep 24, 2014 at 8:28 AM, Emil Uzelac <emil at uzelac.me> wrote:
>>>>>
>>>>>>  ​ Please note that links on http://codex.wordpress.org/Theme_Review
>>>>>> are now changed to accommodate new handbook​
>>>>>> https://make.wordpress.org/themes/handbook/
>>>>>>
>>>>>>  If you spot any errors, please report here and I will fix it :)
>>>>>>
>>>>>> _______________________________________________
>>>>>> theme-reviewers mailing list
>>>>>> theme-reviewers at lists.wordpress.org
>>>>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> theme-reviewers mailing listtheme-reviewers at lists.wordpress.orghttp://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
>>
>>
>
> _______________________________________________
> 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/20140924/64ef3053/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'>&lt?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'>&lt?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