hi maciej
>(6) The Consensus Resolutions proposal recommends an explicit reference
from HTML5 to WCAG 2.0.
>- I don't believe Ian has given a reason for not referencing WCAG.
Tentatively, my recommendation would be to add a citation of the latest WCAG
for >additional accessibility advice, in a general section such as the
introduction or conformance criteria. WCAG provides additional advice on
many features of >the spec, and will likely be updated over time. But I'd
like to verify that this satisfies the goals of those who would like to add
a WCAG reference.
I do not know the answer to whether that would be acceptable or not, in this
case i really think a case needs to be made as to why the spec should not
point people for further guidance to WCAG 2.0 on the accessibility
requirements for text alternatives. More guidance not less should be a good
thing.
html 4 has a link in the image section to a section referencing the various
relevant wai guidelines
http://www.w3.org/TR/html4/appendix/notes.html#accessibility
svg has: http://www.w3.org/TR/SVG11/access.html
if the html 5 spec had a similar section and it was linked to from the img
section this would be acceptable to me at least.
(this sounds like something that should be worked up as 'spec ready text'
perhaps)
in regards to the other recommendation
and that HTML should not provide any guidance that conflicts with WCAG.
it is my understanding the WAI groups are doing a review of the whole HTMl5
spec in time for LC and comments on the current spec contents in regards to
the text alternative examples will be forthcoming.
regards
stevef
2009/8/17 Maciej Stachowiak <mjs@apple.com>
>
> On Aug 16, 2009, at 7:27 PM, Sam Ruby wrote:
>
> Maciej Stachowiak wrote:
>>
>>> On Aug 16, 2009, at 4:45 PM, Sam Ruby wrote:
>>>
>>>> Maciej Stachowiak wrote:
>>>>
>>>> I don't see how trying to better understand the document constitutes an
>>>>> unreasonable burden of proof.
>>>>>
>>>>
>>>> No, but asking for people to justify[1] changes to a spec that has not
>>>> yet been determined to represent consensus does.
>>>>
>>> In a disagreement, everyone should be asked to justify their position.
>>>
>>
>> Agreed.
>>
>> As I pointed out, the current spec text was given detailed
>>> justification[1] based on a great deal of often conflicting feedback.
>>>
>>
>> Do you believe that justification specifically addresses the three points
>> of differences you identified between Ian's and Steven's documents?
>>
>
> Let's take the three points one at a time:
>
> (2) The Consensus Resolutions document does allow <figure> <legend> like
> the spec, but it does not allow @title or a heading for an image-only
> section to describe an image. The current spec allows this, only in the case
> where the contents of the image are unknown.
>
> - I believe the rationale I cited explained why the HTML5 spec offers some
> extra options for describe images in the case where the contents of the
> image are unknown. However, it's not clear to me if this difference is an
> explicit change request, which is why I asked for clarification first. Steve
> already clarified that some of the differences I identified were not
> deliberate.
>
> (6) The Consensus Resolutions proposal recommends an explicit reference
> from HTML5 to WCAG 2.0.
>
> - I don't believe Ian has given a reason for not referencing WCAG.
> Tentatively, my recommendation would be to add a citation of the latest WCAG
> for additional accessibility advice, in a general section such as the
> introduction or conformance criteria. WCAG provides additional advice on
> many features of the spec, and will likely be updated over time. But I'd
> like to verify that this satisfies the goals of those who would like to add
> a WCAG reference.
>
> (7) The Consensus Resolutions document suggests that alt="" (empty alt)
> without role="presentation" on the same element should trigger a non-fatal
> validator warning that recommends adding role="presentation".
>
> - I think Ian's justification explains why empty alt is a fine way to mark
> presentational images. I don't believe he anticipated this particular
> suggested warning, but I think it's reasonable to ask for motivation before
> analyzing the request. I believe Leif's feedback gives some good reasons why
> this warning is not a good idea. I also tentatively think it's not a good
> idea. But I don't want to reject it out of hand without understanding the
> motivation.
>
>
> More generally, I think Ian justified what is currently in the spec, so
> it's reasonable to ask requests for changes to be backed up with some
> reasoning. It doesn't have to be extensive or detailed - I don't want to
> make it a procedural obstacle. But in these cases, a little explanation
> could go a long way towards reaching agreement.
>
>
> I don't see what consensus has to do with anything.The lack of declared
>>> consensus does not make it any less appropriate to expect people to explain
>>> their positions.
>>>
>>
>> I was simply reacting to the fact that you were only asking one side to
>> document their rationale. If Ian's previous answers anticipated and already
>> addressed the specific points of differences, then I apologize. Otherwise,
>> I respectfully submit that everyone should be asked to justify their
>> position.
>>
>
> If the points of difference are clarified, and Ian disagrees, I will expect
> him to justify his position, and will ask him to do so if necessary. On the
> ARIA points, I believe he has already agreed.
>
> Regards,
> Maciej
>
>
--
with regards
Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium
www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html