Re: Working Group Decision on ISSUE-129 aria-mapping

Thanks to the cahirs for providing decisions on the issues.

comments/questions:


On hgroup; currently the spec says that the hrgoup must have a

"heading role, with the aria-level property set to the element's outline
depth <http://dev.w3.org/html5/spec/semantics.html#outline-depth>"

While headings inside hgroup are can have ANY role.

the chairs decision disallows:

" Any changes to how <hgroup> elements are to be interpreted, or how
   headings contained within such an <hgroup> are to be interpreted."

Which means what is currently in the spec stays.

How does that accord with the Chairs statement in regards to hgroup:

"As such, we find that there is no consensus as of yet as to
what this element means, and don't wish for this decision to preclude
any possibility as of yet."

If there is no consensus on the current spec text, will it require that this
is resolved prior to last call?

If there is no consensus why leave the current text as is, where
implementors may well assume that hgroup is to be mapped as specified?

Just to clarify, from my reading of the decision thes are the changes that
need to be applied to the HTML5 spec:


   - *button element, input type="image", input type=button*: allowed roles:
   button, link, menuitem, menuitemcheckbox, menuitemradio,presentation, radio
   - *h1 to h6 element that does have an hgroup ancestor*: no change
   - *hgroup element*: no change
   - *a element that represents a hyperlink* allowed roles: button,
   checkbox, link, menuitem, menuitemcheckbox, menuitemradio, presentation,
   tab, or treeitem.
   - *img element that does not have an empty alt attribute*: default role
   of img. allowed roles: any
   - *H1 to H6* allowed roles:  link, menuitem, menuitemcheckbox,
   menuitemradio,  presentation, tab or treeitem.



Regards
Stevef

[1]
http://dev.w3.org/html5/spec/embedded-content-0.html#annotations-for-assistive-technology-products-aria

On 1 March 2011 02:30, Sam Ruby <rubys@intertwingly.net> wrote:

> The decision follows.  The chairs made an effort to explicitly address
> all arguments presented in the Change Proposals on this topic in
> addition to arguments posted as objections in the poll.
>
> *** Question before the Working Group ***
>
> There is a basic disagreement in the group as to whether or not the role
> attribute should be allowed to override rather than merely to refine the
> defaults provided by HTML elements, in particular elements other than
> <div> and <span>.  The result was an issue, two change proposals, and a
> straw poll for objections:
>
> http://www.w3.org/html/wg/tracker/issues/129
> http://www.w3.org/html/wg/wiki/ChangeProposals/ARIAinHTML5
>
> http://lists.w3.org/Archives/Public/www-archive/2011Jan/att-0019/ccp-129.html
> http://www.w3.org/2002/09/wbs/40318/issue-129-objection-poll/results
>
> == Uncontested observations:
>
>  * We would prefer the web be usable by as many people as possible.
>
>  * Standard controls are preferred over custom controls
>
>  * Web developers break the rules and show no signs of stopping.
>
>  * HTML5 provides the means for authors to add scripting, event handler
>   attributes to any HTML element.  It also provides means to adjust
>   tabindex and visual appearance.
>
>  * It is possible to "violate" the semantics of elements using either
>   JS or CSS.  Furthermore it is possible to do so in ways that can not
>   be reasonably detectable using automated tools.
>
>  * It is not creation of WAI-ARIA that caused authors to re-purpose HTML
>   content.
>
>  * ARIA markup happens to be one of the few ways we can
>   programmatically verify semantic consistency.
>
>  * ARIA conformance requirements could provide an indirect mechanism for
>   automated conformance checkers to flag potential non-conforming uses
>   of HTML elements, which would otherwise be uncheckable.
>
> None of these were decisive.  There were people who supported either of
> these proposals even after taking these facts into consideration.  The
> fact that they were acknowledged up front was appreciated.
>
> Additionally, both sets of proponents make essentially the same claims
> for their respective proposals:
>
>  * 'balances the conformance criteria outcomes in favour of fulfilling
>   ARIA's role as a technology to "improve the accessibility and
>   interoperability of web content and applications"'
>
>  * "disallowing ARIA markup that does not make sense, and allowing
>   markup that does"
>
> We firmly believe that these statements were made in good faith in each
> instance.
>
> === Determining the constituency for this issue
>
> Crucial to deciding this issue is determining the constituency for
> role attributes on elements such as the <a> element.  In particular
> whether this spec text is primarily targeting (to use the vernacular of
> the HTML Design Principles) users, authors, implementors, specifiers, or
> theoretical purity.  As this issue is primarily concerned with
> conformance criteria, the objections that were put forward were
> primarily ones that concerned authors and ones of theoretical purity.
>
> While there is clearly a deep divide over the topic of theoretical
> purity, there also is a very apparent divide over how to categorize the
> set of authors.  Two extended quotes to illustrate this, first from the
> Change Proposal to Change Some Role Mappings:
>
>    Currently the a element is defined in the HTML5 specification as an
>    element that cannot have its native role overriden by ARIA roles.
>    Developers have and will most probably continue to repurpose the a
>    element to achieve desired interface features and style
>    considerations using Javascript and CSS. While re-purposing the
>    element may be non-conforming in HTML5, there is no indication to
>    developers when using a conformance checker, because the changes
>    that are made to make it non conforming cannot be checked using an
>    automated conformance tool. So there is no reason to believe that as
>    long as developers find a reason to repurpose the a element they
>    will stop doing because it says so in the HTML specification. This
>    view is confirmed by the author of the current ARIA in HTML5
>    conformance requirements:
>
>    "@cwilso I think we both know Web developers aren't going to be
>    using the specs as a guide of what they can and can't use"
>
> More from the same Change Proposal:
>
>    Conformance criteria must not used to lessen the probability that
>    developers will use ARIA to make their content accessible, it should
>    be used to ensure that when ARIA is used it is used correctly
>    according to the WAI-ARIA specification and in such a manner that
>    will improve the accessibility of the content it is applied to.
>
> Next from the objections to this change proposal:
>
>    This section first argues that Web developers aren't going to be
>    using the specs as a guide of what they can and cannot use, and
>    promptly uses this to argue for changes to the spec. However, this
>    is nonsensical. We should not design the spec's authoring
>    conformance criteria for people who will ignore the spec; they
>    cannot benefit from such changes. The people who will benefit are
>    those who _do_ care about the spec, and we owe it to them to provide
>    them with the most helpful QA tools (such as validators) as we can,
>    primarily by making the spec's conformance criteria as helpful as
>    possible, catching as many likely mistakes and authoring
>    contradictions as possible.
>
>    This same section claims that it would be bad if validators
>    complained about ARIA values when detecting a mismatch between
>    native semantics and ARIA values, but this is again an argument
>    against a strawman: the specification in fact specifically suggests
>    that validators not do this.
>
>    Finally, this section fails to actually provide concrete use cases
>    for the roles it proposes to add.
>
> And more from these same objections:
>
>    Either authors will follow the spec, in which case they won't need
>    to the loosened requirements proposed, or they won't
>
> In the course of these change proposals, numerous examples of existing
> sites were cited, include jquery, yui, blogspot, jstree, and gmail.  In
> each case, the editor systematically excluded these use cases on the
> basis of errors orthogonal to the introduction of ARIA attributes.
>
> It is the chair's observation that the Working Group is considerably
> more sympathetic to the "copy/paste" culture that has grown up around
> HTML than is evidenced by the exclusion of these use cases.  In short,
> many web sites are produced by copying other sites that work and fixing
> only what needs to be fixed.  In other cases, people inherit legacy
> sites which were produced using practices which are no longer considered
> best practice.  Additionally, backwards compatibility to older browsers
> is specifically mentioned as a motivation for a number of these changes:
>
>    "How is graceful degradation in mixed environments not a use case?"
>
> In short, the chairs find that authors who have mostly working but
> currently inaccessible sites to be an important constituency to be
> addressed and therefore the basis of valid use cases.
>
> == Objections
>
> Based on the above use case, the following objection was found to be
> strong:
>
>  The current text in the HTML5 spec places severe limits as to what
>  ARIA roles can be added to which elements in an effort to dissuade
>  developers from using HTML5 elements and attributes incorrectly.
>
> Accordingly, our attention turned to objections to the proposal to
> "change some role mappings", starting with objections from the Counter
> Change Proposal:
>
>  Conformance criteria must be used to lessen the probability that
>  developers will use ARIA to make their content inaccessible. This can
>  be achieved, for instance, by using them to ensure that when ARIA is
>  used, it is used correctly and in such a manner that will improve the
>  accessibility of the content to which it is applied.
>
> This simply states that the counter change proposal is one way to
> achieve this goal.
>
>  An accurate list would be confusing to authors..., which could
>  conceivably harm accessibility.
>
> We find this to be an argument on behalf of others who are capable of
> speaking for themselves, leading to a conclusion which is speculative.
>
>  No accurate list has been put forward; the only attempts at making
>  such a list so far have been either vague or woefully inaccurate.
>
> This objection is lacking in specifics. If the proposal is adopted bug
> reports on specific inaccuracies are be encouraged.
>
>  Even a vague list would be hard to maintain.
>
> Again, lacking in specifics, and again bug reports are be encouraged.
>
>  Confusion stemming from the inevitable inaccuracies
>
> This objection assumes the conclusion.
>
>  It is important that elements with strong native semantics be
>  specified separately from elements with mere defaults and some
>  constraints
>
> This is no more than a restatement of the point of view that led to the
> elimination valid use cases from consideration.
>
>  An earlier attempt at resolving bug 10444 (mentioned above) created
>  substantial confusion in the specification. For this reason, we should
>  not include the information requested in bug 10444. Since the issue
>  raised in bug 10444 was fixed, and since no complaints were made in
>  the bug regarding the fix, it is unclear what would need to change to
>  further satisfy the request made in this bug.
>
> One incorrect fix does not preclude future corrections.  At this time,
> we have a concrete change proposal, so it is clear what change is being
> requested.
>
>  However, both are non-conforming uses of the <a> element in HTML,
>  because they both use the <a> element for a purpose other than
>  representing a hyperlink... It's unfortunate, but that's what happens
>  when there are valid use cases.
>
> Similarly, we find that starting from such markup (be it a willful
> violation or simply legacy code being maintained) and needing to add
> markup to make the result accessible to be a valid use case.
>
>  In any case, the above examples should not be exposed to ATs as
>  buttons widgets even if they were valid. They are exposed to users as
>  link widgets, not button widgets, and thus that is the appropriate AT
>  behaviour and the appropriate ARIA role.
>
> We fail to follow the logic.  They are exposed differently to AT users
> and non-AT users and therefore this behavior is correct?
>
>  Buttons are supported by HTML, and therefore there is no reason for an
>  author to make a link act like a button to ATs.
>
> We find consensus on the statement that buttons are the preferred
> approach in such situations, but do not find consensus on the statement
> that "there is no reason".
>
>  Making a link act like a button to ATs while leaving it as a link for
>  non-AT users will lead to non-AT users having a confusing experience,
>  since the author will think the link is going to appear as a button to
>  users and may refer to it as such.
>
> The situation being described is exactly the opposite: in case where the
> link acts like a button for non-AT users (by virtue of the techniques
> such as JS), the use case is to enable the use of aria markup to make
> such behave the same for AT users.
>
>  What's important to remember is that there are more than two kinds of
>  user agents; there are at least three...  User agents without CSS
>  support or without scripting support, and certainly without ATs, which
>  always use the default semantics of the elements.
>
> This is potentially a valid objection, but fails to explore what happens
> in the case where such a user agent does not support ARIA, nor the case
> where such a user agent does support ARIA.  In the former case, it does
> no harm.  In the latter case, the result would entirely depend on how
> ARIA was supported.  In the course of this discussion, a large number of
> specific examples were provided where existing sites utilized markup in
> a way that could benefit from the "change some role mappings" proposal,
> and absolutely none were identified which would harm the user agents
> which do not support CSS or scripting but does support ARIA in some
> fashion.  As such this objection was considered to be weaker than than
> the objections to the alternative.
>
>  The only way to keep things consistent amongst all three is to use
>  HTML elements appropriately, and not override their semantics with
>  ARIA.
>
> To date that approach has failed to keep them consistent, nor is there
> any evidence that this trend won't continue.
>
>  defaulting IMG elements to role=img when most IMG elements do not
>  convey images would lead to a poor user experience and cannot be
>  necessary to allow users to interact with images as images.
>
> Potentially a strong objection.
>
>  The suggested text, as well as the text that it was intended to
>  clarify, is merely redundantly repeating ARIA requirements, which are
>  best left to the ARIA specification.
>
> Misrepresents the bug reported, which was '"ARIA restricts usage of this
> role to one per page" is an unclear statement'.
>
>  HGROUP elements are essentially equivalent to headings that contain
>  multiple "paragraphs" (in the sense defined in the HTML
>  specification). They should be conveyed as such to accessibility
>  tools.
>
> This simply states as fact, without providing any evidence, a statement
> which clearly is in dispute.
>
>  We should not make our specifications be confusing, we should not
>  include redundant requirements that are already in other normatively
>  referenced specifications, we should not explicitly state that certain
>  combinations are valid if there's no reason to suspect that they might
>  be invalid.
>
> A potentially valid objection.  It would be stronger if there were
> evidence provided that this principle were systematically applied across
> the specification.
>
> == Arguments not considered
>
> * This issue started out as a philosophic disagreement over the
>  direction of the use of ARIA to mark up various HTML elements.  Based
>  on the direction of the chairs, this disagreement was made tangible
>  first through an expression in the terms of bug reports and ultimately
>  by actual spec text.  A number of objections were stated on the basis
>  of how individual bug reports were worded; others were stated in ways
>  that tend to impeach the credibility of various individuals.  The
>  chairs have declined to enumerate these arguments here.  Instead we
>  are merely stating that none such were considered.
>
> * A number of cases of "it is implicitly argued that".  We did not
>  extract any such implicit arguments, and therefore ignored these
>  counter arguments.
>
> * "missing the entire point of HTML's design philosophy" - if such were
>  documented and consensus could be found on the expression of this
>  philosophy, then perhaps this could have been considered, but failing
>  that we are looking for specific objections.  Conversely, the counter
>  proposal does assert design principles for ARIA.
>
> * "I strongly object to allowing nonsensical roles to be set on
>  elements. ARIA should be used to *augment* the available semantics of
>  HTML as necessary, not to subvert them."  Once this is stripped of
>  emotive terms, what remains is a position statement completely lacking
>  in any substantiation.  Again, the chairs believe that proponents of
>  each proposal believe that their proposal balances conflicting goals
>  in a way that the other does not.
>
> * "I'd advocate for a short clear message in the HTML5 document that
>  says to web developers that for customizing the accessible exposure of
>  their UI go 'here' (ARIA docs)." We only evaluated proposals that
>  actually were put forward.
>
> === Specifics
>
> Now that we have addressed objections based on general principles and
> objections to things other than the what was actually proposed, we turn
> to specifics.  While generally we do not allow people to use bug reports
> as a means to revisit previous decisions over and over again, in this
> case we allowed a large number of bug reports to be pursued as a single
> issue.  The Change Proposal to "change some role mappings" is in fact a
> large change; as such it seems likely that further tweaks in the form of
> bug reports would be necessary.  Furthermore, it is possible that the
> Change Proposal contains some aspects over which we do not find
> consensus.  Looking for specific objections to the Change Proposal
> itself we find:
>
>  defaulting IMG elements to role=img when most IMG elements do not
>  convey images would lead to a poor user experience and cannot be
>  necessary to allow users to interact with images as images.
>
> The Change Proposal asserts that <img> has been mapped to the MSAA role
> 'graphic' in IE since the the 1990s, and that EVERY user agent that maps
> html elements to accessibility APIs, maps the <img> element to an
> image/graphic role in MSAA,IA2, ATK, UIA etc.  These assertions are
> uncontested.  Furthermore, if it were the case that this would lead to a
> poor user experience one would be able to substantiate this assertion by
> citing a large volume of actual bug reports.  None such were cited.
>
>  HGROUP elements are essentially equivalent to headings that contain
>  multiple "paragraphs" (in the sense defined in the HTML
>  specification). They should be conveyed as such to accessibility
>  tools.
>
> In this case, we simply have both sides making assertions as to what the
> HGROUP element is meant to convey, with precious little provided as
> evidence.  As such, we find that there is no consensus as of yet as to
> what this element means, and don't wish for this decision to preclude
> any possibility as of yet.
>
>  Several specific issues:
>  * Allowing slider, scrollbar, or progressbar for <button>, <input
>    type=image>, or <input type=image>
>  * Allowing progressbar, radio, slider, or scrollbar for <a>
>  * Allowing button, checkbox, option, radio, slider, spinbutton, or
>    scrollbar on <h1>-<h6>
>
> In this case, we have a "concern" without a concrete proposal, and on
> the other side we have some "Guiding Factors" without a specific mapping
> showing how these factors apply to these specific situations.  Given
> this state, we endorse the recommendation made in the objections to this
> proposal:
>
>  In order to justify allowing extremely unusual element/role
>  combinations (e.g. <h1 role=scrollbar>), some positive account of <h1>
>  elements being used as scrollbars in the wild should be provided.
>  Absent that, the utility to users of their conformance checker letting
>  them know that they're doing something extremely weird is greater than
>  the utility of repurposing such elements for such different roles.
>
> *** Decision of the Working Group ***
>
> Therefore, the HTML Working Group hereby adopts the ARIA in HTML5:
> change some role mappings Proposal for ISSUE-129, with some specific
> exclusions.  Of the Change Proposals before us, this one has drawn the
> weaker objections.
>
> The specific exclusions are:
>
>  * Any changes to how <hgroup> elements are to be interpreted, or how
>    headings contained within such an <hgroup> are to be interpreted.
>  * Allowing slider, scrollbar, or progressbar for <button>, <input
>    type=image>, or <input type=image>
>  * Allowing progressbar, radio, slider, or scrollbar for <a>
>  * Allowing button, checkbox, option, radio, slider, spinbutton, or
>    scrollbar on <h1>-<h6>
>
> We encourage discussion to continue on these topics, and for the
> discussion to take tangible form as bug reports.  Bug reports on these
> specific topics will be allowed.  Bug reports predicated on the
> assumption that use cases of adding ARIA to existing markup that mostly
> works but doesn't conform to the ideals defined by the specification
> will be summarily closed.
>
> == Next Steps ==
>
> Bugs 10066 is to be REOPENED and marked as WGDecision.  Additionally,
> Issue 129 is to be marked as CLOSED.
>
> Since the prevailing Change Proposal does call for a spec change, the
> editor is hereby directed to make the changes in accordance to the
> change proposal with the exception of the specific exclusions listed
> above.
>
> == Appealing this Decision ==
>
> If anyone strongly disagrees with the content of the decision and would
> like to raise a Formal Objection, they may do so at this time. Formal
> Objections are reviewed by the Director in consultation with the Team.
> Ordinarily, Formal Objections are only reviewed as part of a transition
> request.
>
> == Revisiting this Issue ==
>
> This issue can be reopened if new information come up. Examples of
> possible relevant new information include:
>
> * evidence that correct usage is growing rapidly and that that growth is
>  expected to continue.  Ideally, this usage would include a large
>  subset of the sites that were cited, namely jquery, yui, blogspot,
>  jstree, and gmail.  Alternatively, this evidence could include some
>  rationale as to why the cases which are cited should outweigh the
>  evidence provided by these sites.
>
> * a substantial list of User Agents which are scripting unaware and CSS
>  unaware but are partially ARIA aware to the point where the addition
>  of role attributes produces substantially worse results than not
>  having such information available provides.  This list would need to
>  be accompanied by a specific list of sites that employ such
>  problematic markup.  Ideally such evidence would be provided in terms
>  of first hand statements by implementers of these tools themselves.
>
> * a comprehensive document describing "HTML's design philosophy" over
>  which we have found there to be W3C Consensus within the Working Group
>  over the contents of this document.
>
>