<div dir="ltr">We'll see how long inline responses remain legible. :)<div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span style="color:rgb(80,0,80)">> 0. General thoughts</span><div class="im">
<br>
</div>This is somewhat true, but in many cases it's really true of both --<br>
in general, the intent is that every issue is purely dealt with on the<br>
theme end, and not user content. Core functionality shouldn't<br>
generally be affected, but will require the occasional filter due to<br>
inaccessible defaults. I can provide examples, however.<br></blockquote><div><br></div><div style>Agreed, but we need to be as explicit as possible where the line between core and Theme lies with respect to guideline conformance.</div>
<div style><br></div><div style>In general, a Theme should not fail a guideline for something that is default core output.</div><div style> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">> 1. Images<br>
<br>
</div>I'm entirely happy with mandating that all decorative images are<br>
output with CSS. Absolutely. There is no valid reason in my opinion<br>
for a theme to have decorative images in the HTML.<br></blockquote><div><br></div><div style>I'll propose this as part of the upcoming WordPress 3.6-release guidelines revisions </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
> How does this requirement impact custom header images? Do we need a default<br>
> alt attribute text for custom header images?<br></div></blockquote><div><br></div><div style>What about custom header images, specifically? That's the one instance where a Theme would potentially output a non-decorative image in the template. </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
<br>
</div><div class="im">> The alt-text decision tree would then apply only to user content, and thus<br>
> be outside the review scope<br>
<br>
</div>Not quite - if we would still be allowing images in HTML, just not<br>
purely decorational images, then the theme developer still must<br>
consider the appropriate alt attribute for those images.<br></blockquote><div><br></div><div style>Let's assume that the above guideline about images and CSS will apply. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>> 2. Media auto-playing<br>
<br>
</div>If a theme incorporates an audio player or video player as part of the<br>
theme, this would be part of the theme guidelines; otherwise, user<br>
content. However, we should be covered for that case.<br></blockquote><div><br></div><div style>Most of the time, an audio player is going to be considered as Plugin territory. Nevertheless, the below guideline should suffice in all circumstances, I think. </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
> Regarding sliders: it appears that Themes will be required NOT to auto-start<br>
> sliders, or to provide a user-configurable setting for slider auto-play<br>
> versus manual, defaulting to manual?<br>
<br>
</div>Yes, that's accurate.<br></blockquote><div><br></div><div style>I'll propose this as part of the upcoming WordPress 3.6-release guidelines revisions. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>> 3. Headings<br>
<br>
</div>We certainly do not need to specify which heading to use -- that would<br>
be inappropriate, because the appropriate heading is very much a<br>
decision for the designer.<br>
<br>
The specific areas that really need headings are widgets and content<br>
areas (e.g., must use a heading to start posts or pages).<br></blockquote><div><br></div><div style>So, posts need post titles wrapped in HTML heading tags, and Widgets need titles wrapped in HTML heading tags, and that would cover this guideline? </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I'm not sure more than that is required -- we're indicating<br>
"reasonable" because this is an area where the most important thing is<br>
the presence of headings; the specific choice of which heading to use<br>
is significantly less important. Nice, but less important.<br></blockquote><div><br></div><div style>Agreed. Let's focus on the template/content sub-sections potentially defined by the Theme. I think posts and Widgets is a good definition.</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
><br>
> 4. Link text<br>
><br>
> Since the default core output for the "read more" link is... "read more",<br>
> and since this element is not defined by the Theme, we need to define an<br>
> appropriate read-more link filter to meet this guideline.<br>
><br>
> We need to define all the core-defined links that would fall under this<br>
> guideline.<br>
><br>
<br>
</div>I can do that. This is all in my plug-in WP Accessibility<br>
(<a href="http://wordpress.org/extend/plugins/wp-accessibility/" target="_blank">http://wordpress.org/extend/plugins/wp-accessibility/</a>) and I can pull<br>
the examples from there. Should examples be posted directly in the<br>
Theme Review, or should we provide an example code page?<br></blockquote><div><br></div><div style>We need a good place to put code examples. That's a work in progress. Most importantly, we need a guideline for *what* content should be filtered in place of "read more" (etc.) </div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">> 5. Keyboard Navigation<br>
<br>
</div>The navigation menu itself is, unstyled, fully accessible. The excess<br>
title attributes are a problem, but that's a core issue, and not<br>
appropriate to deal with for theme developers. It's the styling and<br>
use of the menu which are accessibility issues, and these are<br>
definitely theme issues. Usually, it relates to the use of display:<br>
none() to hide sub menus in drop downs and the method used to make<br>
those menus visible.<br></blockquote><div><br></div><div style>Given the prevalence of CSS dropdown menus using display:none / :hover display:inline, this will be an important area to define explicitly, regarding what is unacceptable, and what is necessary to conform to the guideline. </div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">> 6. Contrasts<br><span style="color:rgb(34,34,34)"> </span><br></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><span style="color:rgb(34,34,34)">As far as what would be tested for contrast -- everything. The entire</span><br style="color:rgb(34,34,34)"><span style="color:rgb(34,34,34)">front-end of the site, in all areas.</span></div>
</blockquote><div><br></div><div style>This is where I'm struggling: how do we define this explicitly, and how do we teach reviewers how to evaluate this? </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br><span style="color:rgb(34,34,34)">There are several web-based contrast analyzers. I can recommend one in</span><br></div>
the document - <a href="https://addons.mozilla.org/en-us/firefox/addon/juicy-studio-accessibility-too/" target="_blank">https://addons.mozilla.org/en-us/firefox/addon/juicy-studio-accessibility-too/</a><br>
is a very useful tool for this.<br></blockquote><div><br></div><div style>I'll have to try one of the tools to understand what we're working with. Do these tools scan a URL, and return an evaluation of contrast, in a way that communicates what needs to be addressed? </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br><span style="color:rgb(34,34,34)">That's a good point. We were more going from the concept of the</span><br></div>
impossibility of checking all color settings and the undue burden<br>
associated with that, but it is reasonable to provide a specific<br>
accessibility-focused color scheme as an option.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I would be happy with stating that the review would encompass the<br>
default theme settings or a clearly-labeled accessible color scheme.<br></blockquote><div><br></div><div>Sounds good. I assume that the idea is to encourage/facilitate adoption by both new and existing Themes, but I don't see a lot of Themes making major changes to the default color scheme. </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">> 7. Skip Links<br>
<br>
</div>I assume you mean that we should detail what a conforming skiplink set<br>
up would be? I can do that.<br></blockquote><div><br></div><div style>Exactly. </div><div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">> 8. Forms<br>
><br>
> Since forms are core-defined content, what specific<br>
> wp_list_comments()/comment_form() parameters and filters are required to<br>
> conform to this guideline?<br>
<br>
</div>Like the wp nav menus, this mostly has to do with what people choose<br>
to do *outside* the default -- styling and behavior. If they choose to<br>
implement an AJAX driven comment form, then they need to make sure<br>
that the response from that form is announced to screen readers. If<br>
they use the defaults, they're fine.</blockquote><div><br></div><div style>That gets more difficult, then. How do we define the changes from default core output that would fail the guidelines? </div></div></div></div>