Rationale for meter Attribute Issue 97 Straw Poll is attached. -- Laura L. Carlson
For meter Attribute Issue 97 Straw Poll http://www.w3.org/2002/09/wbs/40318/issue-97-objection-poll/results
Meter Element OBJECTION SUMMARY: 1. Accessibility has not been vetted. 2. Lack of implementation. 3. Lack of styling. 4. Unknown implications of meter being a form element. OBJECTION DETAILS: 1. Accessibility has not been thoroughly vetted or verified. Creating elements that are inherently accessible, that provide accessibility hooks from the get-go, with no additional work by the author could be a win for accessibility. However, the accessibility of the meter element has not been thoroughly vetted or verified. The meter element currently lacks association between action and indicator. It could be hacked with ARIA but if such hacks are needed what is the point of the element in the first place? HTML5 lacks good specification of how the meter element is to be accessible or how AT devices are to render it. It is unknown without investigation the impact this element will have on accessibility. Not considering accessibility at the design stage has been a big mistake for new HTML5 features. As we all know, considering accessibility/bolting it on after the fact is problematic not to mention time consuming (e.g. canvas and video). One of several examples [2] of the time it takes to merely get a topic on the WAI agenda: In 2008 I first requested that PFWG WAI review multimedia <audio> and <video> accessibility requirements [3]. Multimedia requirements are only now being to be discussed [4] in the task force. The April 20, 2010 Accessibility Task Force resolution proclaimed, "We maintain the work item to check these elements and make them better." [5] However, to date no action-plan or timetable or volunteers exist, that I am aware of, to ensure the meter element does indeed become accessible. Accessibility should not fall through the cracks. I voted no on the task force survey regarding these features. [6] My comment included: "The resolution states: "We maintain the work item to check these elements and make them better. How would this work? Do we have volunteers to do this?" as I knew I didn't have the cycles. The **Official** Task Force Work Tracker [7] has no work item being maintained to insure these features are made better. There are no volunteers that I am aware of. There is no plan, which I am aware of, for the Task Force to follow through on their promise. If the meter element is to be included the spec, it should be accessible. I would remove point one of this objection if the proposed action plan [8] or something similar was adopted and the task force fulfilled their commitment to make the element better, so that that the HTML Working Group can be assured that it has satisfied accessibility dependencies. If the task force does not have an official and trackable plan, the time, or the volunteers to fulfill their commitment, the meter element should be dropped from the spec. 2. Lack of implementation. The meter element currently lacks implementation in any browser [9] or assistive technology. It is currently unproven. If it turns out to cause problems in the future, it would be unfortunate to have the HTML5 spec encumbered with it. Meter is unproven. As the decision for issue 76 stated, "being unproven is not necessarily a strong objection to inclusion by itself, but it's worth considering along with other factors." Meter is one of the least mature features in the HTML5. It does not have the maturity level of features inherited from HTML4, or even newer but widely implemented functionality such as <canvas> or <video>. It is not even a thought on HTML5 readiness charts like the one Paul Irish and Divya Manian built [10]. As Jim Allan said on the accessibility task force survey, "Creation of orphaned, poorly implemented or non-implemented elements is not the goal". [11] In many cases assistive technology is an interface between a user with disability and the technology a user with no disability will use to browse the Web. So the behavior of such assistive technology will depend on the output given by a conventional Web browser. And if the conventional Web browser is challenged in rendering a Web content, the challenge will pass on to the assistive technology. In the end, if the behavior is unpredictable it may be unusable. As Ian Hickson has said, "default state for a feature request is for it to be rejected and the default state for a section of the spec was for it to be eventually dropped unless the feature is widely implemented and so important that browser vendors are actually ready to commit money and risk interop issues over it". [12] 3. Lack of styling. Native elements that are not styleable to suit the aesthetic desires of developers and marketing departments will not be used. Elements that are not used are not needed in the spec. They are excess baggage. Default rendering and graceful degradation are unknown. It is critical for CSS to enable the meter element to be styled such that it gives authors significant control of how it is rendered. That is not the case. 4. Unknown implications of meter being a form element. The meter element is currently a form element. It is unknown what happens if the meter element is actually added to a form. It is not specified if the current value is sent with other form element values to the server application or if it isn't. 5. Behavioral user interface elements present a layering violation. As Shelley clarified behavior is not semantics [13]. Tab's change proposal seems to be an attempt at a fallacious or booby trapped low-redefinition [14] of the word "semantic". Redefinition clouds the discussion. The issue concerns separating or mixing structure, presentation, AND behavior in behavioral user interface elements. Separation is architecturally sound. "A specification SHOULD allow authors to separate content from both presentation and interaction concerns." [15]. Keeping behavior separate and not integrating it into elements and has served us well to date, as witness the many and sophisticated applications we use today. I have always used the three legged stool approach to web standards. Separate structure, presentation, AND behavior. I have concerns if introducing behavior into HTML is the right direction. Seems like contamination to me...like putting presentational elements in that are hard to get out once they are there. It is reminiscent of adding behavior such as marquee and blink elements. Behavioral user interface elements may be the bane of HTML5. If behavior is not well thought out, it can be a disaster. As Ian Hickson has said, layering violations "lead to complicated interdependencies. These tend to snowball as the technology matures. Layering violations are actually one of the most insidious problems in language design, because they appear innocuous at first, and tend to accrete over time, leading eventually to a disaster." [16] If widget elements are needed for accessibility, I agree with Benoit Piette [17]. They should be completely separate them from structural elements. Such elements could possibly go into a document of their own, to support modularity and might be reusable in other languages. CONCLUSION: The meter element is insufficiently thought out or as Leif has termed such things: it is "half baked". It has unvetted accessibility, lack of implementation, lack of styling, unknown implications of it being a form element, and presents a layering violation. In Jon Gunderson's no vote on the accessibility task force survey [17], he commented, "I think the more we can simplify HTML 5 elements the easier it will be to get HTML 5 and accessibility implemented and to explain to authors how to create accessible content in HTML5. Browser developers will probably not implement these elements anyway if they don't like them or do it inconsistently. There is a lot in HTML5 and I think we have enough to discuss without spending time on elements that may never be implemented." I agree. REFERENCES: [1] http://realtech.burningbird.net/web/html5/progress-element-truly-progressive [2] http://www.w3.org/html/wg/wiki/HTMLRequestsPFresponse [3] http://lists.w3.org/Archives/Public/public-html/2008Sep/0421.html [4] http://lists.w3.org/Archives/Public/public-html-a11y/2010May/0084.html [5] http://lists.w3.org/Archives/Public/public-html-a11y/2010Apr/0183.html [6] http://www.w3.org/2002/09/wbs/44061/200404_ftf-proposals/results#xq5 [7] http://www.w3.org/WAI/PF/HTML/track/ [8] http://lists.w3.org/Archives/Public/public-html/2010Apr/1301.html [9] http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28HTML5%29#Elements [10] http://html5readiness.com/ [11] http://www.w3.org/2002/09/wbs/44061/200404_ftf-proposals/results#xq5 [12] http://lists.w3.org/Archives/Public/public-html/2008Jun/0140.html [13] http://www.w3.org/html/wg/wiki/ChangeProposals/removedetails#Behavior_is_not_semantics [14] http://www.fallacyfiles.org/redefine.html#LowRedef [15] http://www.w3.org/TR/webarch/#pci (Architecture of the World Wide Web, Volume One. W3C, 2004.) [16] http://lists.w3.org/Archives/Public/public-html-a11y/2010Apr/0250.html [17] http://lists.w3.org/Archives/Public/public-html/2010May/0006.html [18] http://www.w3.org/2002/09/wbs/44061/200404_ftf-proposals/results#xq5 -- Laura L. Carlson
