<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span style="color:rgb(80,0,80)">> What about custom header images, specifically? That's the one instance where</span><br>
<div class="im">
> a Theme would potentially output a non-decorative image in the template.<br>
><br>
<br>
</div>Then the custom header image needs to have an appropriate alt<br>
attribute. What that alt attribute is, however, would be determined by<br>
the content of the image -- if it includes text, that text must be in<br>
the alt attribute. I think that if a theme provides an image, then<br>
that image needs to have an alt attribute. An empty alt attribute is<br>
entirely acceptable, assuming that the image doesn't require alternate<br>
content.<br></blockquote><div><br></div><div style>The reason I ask about the custom header image is because, by definition, the Theme won't have any way to know what the image content is. If an empty alt tag is appropriate and acceptable, that might be the best approach.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
</div>The key thing is that the read more text should be unique to the link<br>
it points to. Since all contexts that WP uses this text in pertain to<br>
posts, the standard content would be to include the post title as<br>
unique text. I'll make this clear in the guidelines.<br></blockquote><div><br></div><div style>Perfect. That's where I'm headed: objective, explicit guidelines and recommendations. There will be a potentially steep learning curve for developers and reviewers, so we want to lessen the slope of that curve as much as feasible.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
>> > 5. Keyboard Navigation<div class="im">
<br>
</div>The important thing comes out of testing: keyboard testing is trivial,<br>
since it just involves navigating the menu using a keyboard. For<br>
screen readers, it's just a matter of *not* using display: none. But<br>
this can be documented explicitly.<br></blockquote><div><br></div><div style>Yes, please. I anticipate that trying to move away from display:none for dropdown menus will be a considerable paradigm shift for a lot of developers.</div>
<div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">>> > 6. Contrasts<br>
<br>
</div>Scanning for contrast is actually an incredibly difficult problem, due<br>
to the CSS cascade. The algorithms for determining what colors are<br>
actually involved in a given contrast pair is very difficult. So, the<br>
tools do scan the URL and return an evaluation of contrast, flagging<br>
potential issues. However, a visual confirmation of the issues is<br>
necessary, because not all flagged contrast errors will be real: some<br>
will be due to the algorithm in use detecting the wrong<br>
background/foreground element pair.<br>
<br>
This is going to take some learning, ultimately. Contrast is very easy<br>
to evaluate, once you get comfortable with the tools and the concept<br>
-- but it does take judgement to test.<br></blockquote><div><br></div><div style>I anticipate that this will be the area of greatest need for education.</div><div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><span style="color:rgb(34,34,34)">>> > 8. Forms</span></div><div class="im">
><br>
> That gets more difficult, then. How do we define the changes from default<br>
> core output that would fail the guidelines?<br>
><br>
<br>
</div>I'm not sure we can specifically delineate all possibilities.</blockquote><div><br></div><div style>That's always true, and as I often say: we do not want the Guidelines to emulate the Code of Federal Regulations. :) The trick will be finding the right balance between subjectivity and onerous specificity. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Any<br>
change that results in form responses not being exposed to assistive<br>
technology would be a failure. Similarly, any customization that<br>
results in the removal of labels would be a failure. <br></blockquote><div><br></div><div style>These are good examples.</div><div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We can't say that all changes in core output would be failures,<br>
because it can also be improved -- but the numbers of ways that<br>
failures can be generated is fairly broad.<br>
<br>
The methods for testing are fairly straightforward, however. I can<br>
list those out, if it would help.</blockquote><div><br></div><div style>Absolutely. The more examples/test cases we can define, the easier it will be for everyone. </div></div></div></div>