Re: Null change proposals for ISSUE-31, ISSUE-41, ISSUE-80, and ISSUE-88

ian wrote:
"Another change proposal suggests removing all advice for authors writing
alternative text, moving it to other documents. Historically, we have
tried that (HTML4 had virtually no advice) and we have found it to be a
poor solution: authors assume it is easy to write alternative text and
thus do not attempt to learn anything about it. We need to try having such
information as "in your face" as possible. Having additional documents
would be additionally helpful, but does not preclude having detailed
advice in the HTML spec itself."

I am not adverse to having the content of the HTML5: Techniques for
providing useful text alternatives
[http://dev.w3.org/html5/alt-techniques/] replace in total the current
author advice and conformance requirements content in HTML5. This
would satisfy your desire to keep the 'information as "in your face"
as possible'

I would advocate that as well as keeping the "HTML5: Techniques for
providing useful text alternatives" available as a seperate document.

will add this to my change proposal.

regards
stevef

On 23 March 2010 22:33, Ian Hickson <ian@hixie.ch> wrote:
>
> ISSUE-31
> ========
>
> SUMMARY
> There is no problem and the proposed remedy is to change nothing.
>
> RATIONALE
> There is no problem.
>
> Another change proposal suggests removing all advice for authors writing
> alternative text, moving it to other documents. Historically, we have
> tried that (HTML4 had virtually no advice) and we have found it to be a
> poor solution: authors assume it is easy to write alternative text and
> thus do not attempt to learn anything about it. We need to try having such
> information as "in your face" as possible. Having additional documents
> would be additionally helpful, but does not preclude having detailed
> advice in the HTML spec itself.
>
> A second change proposal suggests allowing otherwise non-conforming
> content to be conforming based on the presence of ARIA attributes.
> However, this is a layering violation and a language design error. ARIA is
> intended to only affect accessibility API mappings (and thus ATs).
> Features such as alt="", however, are relevant far beyond AT users, for
> example to text browsers. It would be wrong, therefore, to make solutions
> that exclusively affect accessibility APIs be a suitable alternative for
> solutions that are necessary for UAs that do not use accessibility APIs.
>
> DETAILS
> Change nothing.
>
> IMPACT
>
> POSITIVE EFFECTS
> Having authoring advice will help advise authors.
> Having conformance requirements independent of AT APIs will ensure that
> authors are encouraged to write documents that are optimal even for users
> that do not use ATs.
>
> NEGATIVE EFFECTS
> None.
>
> CONFORMANCE CLASS CHANGES
> None.
>
> RISKS
> None.
>
>
> ISSUE-41
> ========
>
> SUMMARY
> There is no problem and the proposed remedy is to change nothing.
>
> RATIONALE
> "Decentralized extensibility" is not a problem description.
>
> The issue description says that "The HTML5 specification does not have a
> mechanism to allow decentralized parties to create their own languages,
> typically XML languages, and exchange them in HTML5 text/html
> serializations", but to all appearances this is a good thing, not a
> problem. Why would we want to encourage vendors to create proprietary
> languages and exchange them as text/html? The whole point of having a
> standard is that people shouldn't do that.
>
> Another change proposal suggests a convention should be provided for
> preventing vendor-specific non-standard extensions from clashing with
> themselves and future standard development. This is a real problem, but it
> is inappropriate to address this problem via the change proposal process
> since it corresponds to an open bug and does not have any bearing on the
> topic given by the issue description (as quoted above): such non-standard
> extensions would by definition not be "allowed"; they would merely be
> handled by the provision of a convention for experimentation in non-
> validating documents (as, for instance, with CSS vendor prefixes).
>
> DETAILS
> Change nothing.
>
> IMPACT
>
> POSITIVE EFFECTS
> By not providing solutions without corresponding problems, we avoid the
> danger of designing solutions that do not address any real problems. We
> also avoid encouraging people to use these solutions to address problems
> that either should not be addressed at all, or to address problems that
> should be addressed in other ways that are far more appropriate.
>
> NEGATIVE EFFECTS
> None.
>
> CONFORMANCE CLASS CHANGES
> None.
>
> RISKS
> None. We can always add further extension mechanisms later if an actual
> problem is found to exist after all.
>
>
> ISSUE-80
> ========
>
> SUMMARY
> There is no problem and the proposed remedy is to change nothing.
>
> RATIONALE
> There is no problem.
>
> Another change proposal suggests disallowing the use of the title=""
> attribute to provide titles for images, instead requiring the use of
> separate elements for this purpose. This makes writing accessible pages
> harder and therefore is likely to have negative effects on the overall
> accessibility of the Web.
>
> DETAILS
> Change nothing.
>
> IMPACT
>
> POSITIVE EFFECTS
> None.
>
> NEGATIVE EFFECTS
> None.
>
> CONFORMANCE CLASS CHANGES
> None.
>
> RISKS
> None.
>
>
> ISSUE-88
> ========
>
> SUMMARY
> There is no problem and the proposed remedy is to change nothing.
>
> RATIONALE
> There is no problem.
>
> Another change proposal suggests a number of changes, but those changes
> have by and large already been made and therefore it is hard to provide
> coherent counter-arguments to the remaining differences: it isn't clear
> which are merely editorial choices and which are intended to be actual
> proposed changes.
>
> DETAILS
> Change nothing.
>
> IMPACT
>
> POSITIVE EFFECTS
> None.
>
> NEGATIVE EFFECTS
> None.
>
> CONFORMANCE CLASS CHANGES
> None.
>
> RISKS
> It is possible that some of the changes in the other change proposal would
> be worth making, but it is hard to tell which changes that would be since
> that proposal is out of date.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
>



-- 
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

Received on Wednesday, 24 March 2010 20:01:03 UTC