- From: Paul Cotton <Paul.Cotton@microsoft.com>
- Date: Tue, 19 Feb 2013 19:56:57 +0000
- To: Janina Sajka <janina@rednote.net>, "public-html-admin@w3.org" <public-html-admin@w3.org>, W3C WAI Protocols & Formats <w3c-wai-pf@w3.org>
- CC: HTML Accessibility Task Force <public-html-a11y@w3.org>, Sam Ruby <rubys@intertwingly.net>, Maciej Stachowiak <mjs@apple.com>, "Michael(tm) Smith (mike@w3.org)" <mike@w3.org>, Judy Brewer <jbrewer@w3.org>, "Michael Cooper" <cooper@w3.org>
My access problem was intermittent and was solved when the W3C Systems Team rebooted the server. /paulc Paul Cotton, Microsoft Canada 17 Eleanor Drive, Ottawa, Ontario K2E 6A3 Tel: (425) 705-9596 Fax: (425) 936-7329 -----Original Message----- From: Paul Cotton Sent: Tuesday, February 19, 2013 2:34 PM To: 'Janina Sajka'; public-html-admin@w3.org; W3C WAI Protocols & Formats Cc: HTML Accessibility Task Force; Sam Ruby; Maciej Stachowiak; Michael(tm) Smith (mike@w3.org); Judy Brewer; Michael Cooper Subject: RE: HTML-A11Y Task Force Consensus Decision and Request to Publish >The specification is provided at: > > https://dvcs.w3.org/hg/html-proposals/raw-file/b63325998cc1/longdesc1/longdesc.html I cannot access the above URL. Is it correct? /paulc Paul Cotton, Microsoft Canada 17 Eleanor Drive, Ottawa, Ontario K2E 6A3 Tel: (425) 705-9596 Fax: (425) 936-7329 -----Original Message----- From: Janina Sajka [mailto:janina@rednote.net] Sent: Monday, February 18, 2013 7:06 PM To: public-html-admin@w3.org; W3C WAI Protocols & Formats Cc: HTML Accessibility Task Force; Sam Ruby; Maciej Stachowiak; Paul Cotton; Michael(tm) Smith (mike@w3.org); Judy Brewer; Michael Cooper Subject: HTML-A11Y Task Force Consensus Decision and Request to Publish Colleagues: This email is to announce a consensus in the HTML-A11Y Task Force to request First Public Working Draft (FPWD) publication of an HTML extension specification for a long text description mechanism as an attribute to the image element, and named longdesc. The specification is provided at: https://dvcs.w3.org/hg/html-proposals/raw-file/b63325998cc1/longdesc1/longdesc.html We hereby request publication approval from the HTML and WAI_PF Working Groups as provided under Plan 2014. We further request PF and HTML Staff Contact assistance to insure all necessary copyright, status, and other pertinent W3C notices are incorporated in this document prior to publication. The Task Force decision to call for a consensus on publishing this specification as an FPWD is logged at: http://www.w3.org/2012/11/15-html-a11y-minutes.html#item01 Additional steps performed to validate the Task Force consensus for this request include: I. A Call for Consensus to publish this specification as a FPWD was posted on the TF list on 20 November last: http://lists.w3.org/Archives/Public/public-html-a11y/2012Nov/0091.html II A draft summary of objections received together with comments on the disposition of each objection received was prepared (as discussed by the TF in teleconference as minuted at http://www.w3.org/2012/11/29-html-a11y-minutes.html#item04 and following). This summary was published to the TF list with request for concerns and corrections should our summary incorrectly represent any aspect of the objections received: http://lists.w3.org/Archives/Public/public-html-a11y/2012Dec/0087.html III. A second draft summary of objections and their dispositions was announced: http://lists.w3.org/Archives/Public/public-html-a11y/2013Jan/0112.html There were no further objections to this summary from commenters. III. The Task Force Co-Chairs and relevant Domain Leads addressed two remaining editorial clarifications in the summary of dispositions to objections received. As agreed by the Task Force (and noted in the 14 February minutes at http://www.w3.org/2013/02/14-html-a11y-minutes.html), final (48-hour) call for any remaining editorial concerns was published twice, on February 13 and again on February 14, at: http://lists.w3.org/Archives/Public/public-html-a11y/2013Feb/0053.html http://lists.w3.org/Archives/Public/public-html-a11y/2013Feb/0056.html There being no objections to this final draft, it is included below in this email as a Task Force Consensus statement. IV. resolutions for longdesc spec... Summary of Objections and their Dispositions A.) Technical Objections Received 1. David McDonald stated that an example of an image with null alt text and a longdesc would contradict a WCAG technique. Resolution: fixed. A bug was raised 20048 to track this. The example was removed. 2. David also stated that longdesc URLs which were internal references to the page were a new feature and didn't work. Resolution: Invalid. The HTML4 definition, which allows internal page references, has been correctly implemented in pwWebspeak, Opera, iCab, the Firefox extension, and other examples in the wild. Current implementations (such as IE/JAWS, and some others) that do not recognize internal page references should be cited as being incorrect. 3. James Craig and Matt Turvey both stated that an image description should be available to all users. Nobody disagreed, and several people agreed. A bug was raised[3] to track this. Resolution: Fixed. The latest specification draft addresses this by more clearly stating that the requirements apply to all users, not just assistive technology. The proposed specification already requires user agents to enable users, as well as assistive technologies, to access the functionality. The Opera, iCab and Firefox implementations all do this. The NVDA implementation was held back with the explicitly stated hope that the functionality would be made available to all users through the browser. 4. Matt Turvey suggested that the use case of making it straightforward to teach the use of description mechanism be removed, because it could be interepreted in a way that casts a bad light. Resolution: Won’t Fix: The use case has value and should be retained. 5. Matt Turvey stated that poor implementation of longdesc means that it is more harmful than beneficial. Various responses have been made that while poor implementation is a known issue, any harm it may do is outweighed by the benefit of good implementations that exist. Resolution: Won’t Fix. This is a point in contention, and the case that longdesc is harmful has clearly not been proven. 6. Matt Turvey suggested that the specification could be changed to state that it should only be used in cases where the audience was controlled. Resolution: Won’t Fix. This suggested restriction runs counter to the benefits of extending longdesc to all users which was recognised as valuable by the Task Force as noted in point 3 above. 7. Matt Turvey, James Craig, and Silvia Pfeiffer suggested the specification could be changed to state that longdesc is obsolete. Resolution: Won’t Fix In a specification of a single feature, this makes no sense. The question might be relevant to the HTML Working Group if it wants to consider incorporating this extension directly into the HTML specification, but that isn't even being discussed at this point. B.) Issues of process:* The following resolutions are for points raised that are purely issues of process: 1P Matt Turvey suggested we haven't addressed the objections from the original HTMLWG poll and decision. Resolution: Invalid The decision was overturned. The question of whether a draft makes a reasonable FPWD does not depend on it meeting all technical objections, and therefore it is reasonable to file a bug for any given technical issue (as has been done in some cases already) and proceed with publishing. 2P Matt Turvey suggested none of the use cases (except Teaching Accessible Development) appear to specifically require longdesc. Resolution: Invalid. Use cases do not require a specific solution. They lead to requirements, and we standardise something that meets those requirements. 3P Matt Turvey suggested that the use cases can already be better addressed with existing, widely supported techniques. James Craig requested that "some mechanism other than longdesc be used". Resolution: Invalid. It is clearly possible to meet any given use case's requirements, and even a subset of all of them, with many kinds of solutions. There is no reason an alternative cannot be proposed as an extension specification. We are not discussing other proposals, but whether it is reasonable to publish a draft of one proposed solution. Matt did not identify the relevant solutions he claims exist, and James did not provide an alternative proposal, nor explicitly object to publication of this FPWD. 4P Matt Turvey suggested that if there is a use case that specifically requires programmatic determinability of a long description link as distinct from a normal link, but is not satisfied by using rel=longdesc, this should be included. Resolution: Invalid. Use cases should identify problems that need solutions, not be reverse-engineered from solutions (nor from hypothetical proposals for solutions). There is no reason an alternative cannot be proposed as an extension specification. We are not discussing other proposals, but whether it is reasonable to publish a draft of one proposed solution. 5P Matt Turvey suggested that as Geoff Freed is currently compiling evidence for the Task Force that some educational publishers might be about to start using longdesc, it may be worth waiting until we have that evidence available. Resolution: Invalid. If this were the only evidence, or critical for a decision on whether to proceed to Recommendation, it might be worth waiting for it. This CfC is about developing the specification as a Working Draft and it is unnecessary to wait for all possible knowledge before moving forward. Geoff Freed himself provided further evidence, and clarification that it is not worth waiting for information that is unlikely to be provided to a public mailing list. 6P Matt Turvey noted that Sam Ruby suggested a "course correction" may be required on longdesc, citing the absence of correct longdesc usage in Steve Faulkner's survey of the top 10,000 website home pages. Matt questioned whether this spec is the kind of course correction that will convince HTMLWG members to support longdesc. Resolution: Invalid. It's difficult to guess if Sam is right. What Sam suggested is not a process requirement, nor the chairs' opinion, just an idea of his own. Not publishing a draft of the spec seems unlikely to help determine the answer to Matt's (restatement of Sam's) question. This request is sent on behalf of the HTML-A11Y Task Force Co-Chairs: Janina, Charles, and Steve -- Janina Sajka, Phone: +1.443.300.2200 sip:janina@asterisk.rednote.net Email: janina@rednote.net Linux Foundation Fellow Executive Chair, Accessibility Workgroup: http://a11y.org The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) Chair, Protocols & Formats http://www.w3.org/wai/pf Indie UI http://www.w3.org/WAI/IndieUI/
Received on Tuesday, 19 February 2013 19:58:20 UTC