A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.

To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).

Change Proposal for ISSUE-129: Difference between revisions

From WHATWG Wiki
Jump to navigation Jump to search
No edit summary
 
(29 intermediate revisions by the same user not shown)
Line 2: Line 2:


Don't allow people to use ARIA to write inaccessible documents.
Don't allow people to use ARIA to write inaccessible documents.
__TOC__


== Rationale ==
== Rationale ==
Line 11: Line 13:
The current section defining the relationship between the HTML and ARIA specifications uses an approach eminently suited for addressing accessibility in HTML. It is defined in terms that the ARIA specification uses, provides the information needed by implementors, authors, and validator writers, and provides a coherent and concise set of UA and document requirements.
The current section defining the relationship between the HTML and ARIA specifications uses an approach eminently suited for addressing accessibility in HTML. It is defined in terms that the ARIA specification uses, provides the information needed by implementors, authors, and validator writers, and provides a coherent and concise set of UA and document requirements.


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. The current specification text achieves this: it balances the conformance crtieria outcomes in favour of fulfilling ARIA's role as a technology to "improve the accessibility and interoperability of web content and applications" <ref>http://www.w3.org/TR/wai-aria/complete#abstract</ref>, disallowing ARIA markup that does not make sense, and allowing markup that does. It does not allow overrides of widget roles by unrelated widget roles, or allow overrides of semantic roles by unrelated semantic roles, nor does it allow for overriding of aspects of elements. It allows roles to be overriden by their children in the ARIA role taxonomy where that makes sense, and disallows it where it does not. (The role taxonomy in ARIA is based on a role's features; it does not follow that children are always more specific versions of the same concept. For instance, menuitemradio and menuitemcheckbox are not interchangeable in user interfaces, but in ARIA the former is a child of the latter.)
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. The current specification text achieves this: it 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" <ref>http://www.w3.org/TR/wai-aria/complete#abstract</ref>, disallowing ARIA markup that does not make sense, and allowing markup that does. It does not allow overrides of widget roles by unrelated widget roles, or allow overrides of semantic roles by unrelated semantic roles, nor does it allow for overriding of aspects of elements. It allows roles to be overridden by their children in the ARIA role taxonomy where that makes sense, and disallows it where it does not. (The role taxonomy in ARIA is based on a role's features; it does not follow that children are always more specific versions of the same concept. For instance, menuitemradio and menuitemcheckbox are not interchangeable in user interfaces, but in ARIA the former is a child of the latter.)


=== Bug 10444: Requesting a list of all the elements that do not have a default ARIA role ===
=== Bug 10444: Requesting a list of all the elements that do not have a default ARIA role ===
Line 26: Line 28:
* Confusion stemming from the inevitable inaccuracies listed in the previous points will likely lead to implementation mistakes, leading to poor interoperability, which would harm accessibility (since this is an accessibility feature).
* Confusion stemming from the inevitable inaccuracies listed in the previous points will likely lead to implementation mistakes, leading to poor interoperability, which would harm accessibility (since this is an accessibility feature).


'''In summary: no use cases, maintenance nightmare, might even harm accessibility.'''
'''Summary: no use cases, maintenance nightmare, might even harm accessibility.'''


=== Bug 10462: Merge the table defining strong native semantics and the table listing role and state constraints into a single table ===
=== Bug 10462: Merge the table defining strong native semantics and the table listing role and state constraints into a single table ===
Line 33: Line 35:
Providing unclear or ambiguous guidance to authors about how ARIA can be used in HTML5 is likely to negatively impact the correct use of ARIA on the Web. Indeed, failing to provide such information does a disservice to both Web developers, who author ARIA-supporting applications, and to users with disabilities, who rely on those annotations to make use of those applications.
Providing unclear or ambiguous guidance to authors about how ARIA can be used in HTML5 is likely to negatively impact the correct use of ARIA on the Web. Indeed, failing to provide such information does a disservice to both Web developers, who author ARIA-supporting applications, and to users with disabilities, who rely on those annotations to make use of those applications.


Therefore, it is imperative that the information provided be structured coherently, be compatible with ARIA terminology, and be correct. To this end, it is important that elements with strong native semantics be specified separately from elements with mere defaults and some constraints, and that both sets of requirements be properly introduced with RFC2119 and ARIA terminology. This is what is done in the specification as it stands today.
Therefore, it is imperative that the information provided be structured coherently, be compatible with ARIA terminology, and be correct. To this end, it is important that elements with strong native semantics be specified separately from elements with mere defaults and some constraints, and that both sets of requirements be properly introduced with RFC2119 and ARIA terminology. This is what is done in the specification as it stands today; in part, this is done by keeping the tables separate.
 
'''Summary: keeping the tables separate is key to maintaining the clarity of the specification.'''
 
=== Bug 10603: Confusion arising from an earlier attempt at resolving the aforementioned bugs ===
Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10603
 
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.
 
'''Summary: issue seems to already be resolved.'''


'''In summary: keeping the tables separate is key to maintaining the clarity of the specification.'''
=== Bugs 8000 and 10448: Allow links to be described as scroll bars, buttons to be described as progress bars, etc ===
Bugs: http://www.w3.org/Bugs/Public/show_bug.cgi?id=8000; http://www.w3.org/Bugs/Public/show_bug.cgi?id=10448


=== Bug 10448: Allow links to be described as scroll bars, buttons to be described as progress bars, etc ===
''The two bugs are more or less duplicates of each other.''
Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10448


No use cases have been provided to explain the benefit of allowing links to be described as scroll bars, buttons to be described as progress bars, and so forth, despite repeated requests for use cases.
No use cases have been provided to explain the benefit of allowing links to be described as scroll bars, buttons to be described as progress bars, and so forth, despite repeated requests for use cases.


It has been suggested that occurances of the following need role="button" to be made accessible:
It has been suggested that occurrences of the following need role="button" to be made accessible:


   <a href="#" onclick="action()">...</a>
   <a href="#" onclick="action()">...</a>
Line 76: Line 87:
Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10449
Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10449


No use cases have been provided to explain the benefit of allowing headings to be described as spinbuttons, checkboxes, and so forth, despite repeated requests for use cases.
No use cases have been provided to explain the benefit of allowing headings to be described as spinbuttons, checkboxes, and so forth, despite ''repeated'' requests for use cases.


In the absence of concrete use cases, and given the preposterousness of using an element whose semantic is "heading" to mark up a checkbox or scrollbar, of all things, it would do authors a disservice not to flag such questionable cases.


''See also the section below explaining why use cases are necessary for such features.''
''See also the section below explaining why use cases are necessary for such features.''
Line 87: Line 98:
Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10481
Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10481


For most images, role=img is unsuitable, because the IMG element's main purpose (from the point of view of an AT user) is not to convey an image, but to convey text. For example, an image as part of a link conveys information about the link. An image of a company logo conveys the name of a company. An image of social networking site conveys the name of that site. Informally, if one browses the Web one will quickly find that most
images are either presentational (alt=""), logos, text in buttons or links, or icons. Very few are actually interesting from the point of view of conveying actual graphical information. Even on pages where one would think there were interesting images, they are in the minority — for example, the Flickr page for a photograph has on the order of 20 images only one of which is really an image from the AT user's perspective.
 
Using role=img for an IMG element is therefore likely to lead to a relatively poor user experience. Rather than getting on with the job of letting the user interact with the page, an AT user would be constantly reminded that the page is full of images, something which a non-AT user would never think of.


'''Summary: '''
It is sometimes argued that the reason role=img is supposedly necessary is that without it, image-specific user interface commands, e.g. to view the image in a separate tab, or to obtain the image's dimensions or URL, would be unavailable. However, such behaviour would be nonsensical. A user may still wish to interact with a presentational image (with role=presentational, not role=img), and a non-IMG element (e.g. DIV) with role=img would not get image-specific user interface commands (those commands would be meaningless). The two issues are thus obviously orthogonal. role=img only controls how the element is presented by the AT by default; it should not prevent users from interacting with images as images if they so desire.
 
'''Summary: 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.'''


=== Bug 10493: Requesting additional prose in the HTML spec stating that certain roles defined in the ARIA spec have restrictions on their use defined in the ARIA spec ===
=== Bug 10493: Requesting additional prose in the HTML spec stating that certain roles defined in the ARIA spec have restrictions on their use defined in the ARIA spec ===
Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10493
Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10493


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. Having redundant text courts mistakes (as the original text presumably demonstrated, assuming the proposed correction was itself correct), which then results in reader confusion and, in the worst case, interoperability inconsistencies as different implementations interpret each implied instruction independently.


'''Summary: '''
'''Summary: suggested clarification is out of scope for the specification.'''


=== Bug 10592: Request regarding the ARIA role of heading elements inside HGROUP elements ===
=== Bug 10592: Request regarding the ARIA role of heading elements inside HGROUP elements ===
Line 104: Line 120:


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 means setting the "heading" role on the HGROUP element, and treating the Hx elements in the HGROUP element the same way as paragraphs are treated normally.
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 means setting the "heading" role on the HGROUP element, and treating the Hx elements in the HGROUP element the same way as paragraphs are treated normally.
<!--'''Summary: '''-->
 
'''Summary: what the spec requires is the appropriate set of roles for this situation.'''


=== Bug 10594: Move some requirements regarding ARIA attributes into a separate table ===
=== Bug 10594: Move some requirements regarding ARIA attributes into a separate table ===
Line 114: Line 131:


We should, indeed, include detailed requirements regarding the constraints placed on ARIA attributes in different situations. For example, it is important that the aria-disabled="" attribute be set to "true" on any control that is disabled (not any control that has the disabled="" attribute specified, which is a different matter). It is important that we restrict aria-valuemax="" when set on INPUT elements in the Range state to the maximum value (not necessarily the value given in the max="" attribute). There are a number of such requirements. The specification requires all the ones that make sense.
We should, indeed, include detailed requirements regarding the constraints placed on ARIA attributes in different situations. For example, it is important that the aria-disabled="" attribute be set to "true" on any control that is disabled (not any control that has the disabled="" attribute specified, which is a different matter). It is important that we restrict aria-valuemax="" when set on INPUT elements in the Range state to the maximum value (not necessarily the value given in the max="" attribute). There are a number of such requirements. The specification requires all the ones that make sense.
<!--'''Summary: '''-->
=== Bug 10603: ? ===
Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10603


'''Summary: what the spec says is already what is appropriate for these requirements.'''
 
'''Summary: '''


=== Bug 10903: Requesting more introductory text ===
=== Bug 10903: Requesting more introductory text ===
Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10903
Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10903


This is out of scope for this issue since it is already a part of ISSUE-109, which has already been taken to poll.


'''Summary: '''
'''Summary: out of scope.'''


=== Bug 8000: Allow authors to use elements in ways that contradict their semantics ===
=== Why use cases are needed to justify allowing particular roles in particular situations ===
Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=8000
 
 
'''Summary: '''


=== Why use cases are needed to justify allowing particular roles in particular situations ===
Using a role in a particular situation is either reasonable, on unreasonable. For example, labeling list items (LI elements) as role="treeitem" is reasonable, since one can use nested lists to create trees without violating any semantics (a tree can in fact be described as a structure of nested lists). On the other hand, labeling a list item as a role="heading" is unreasonable, because there is no need for it and thus occurrences of such markup are highly likely to be indicative of either underlying semantic misuse (which can lead to usability problems in non-AT non-CSS/JS UAs, processing problems in markup analysis tools like search engines, maintenance difficulties, etc), or of unintentional markup errors (for which authors would benefit from validators and other QA tools flagging the problem).


Thus, to craft the conformance criteria for HTML's use of ARIA, we have to figure out what features fall into the "reasonable" camp and which fall into the "unreasonable" camp. (This is supported by ARIA itself, which provides hooks for markup languages to use to indicate exactly this categorisation — that's the whole point of having "strong native semantics", which is one of the main things the accessibility annotations section defines.) To do this in a consistent way, the main tool we have at our disposal is the consideration of use cases. This is why use cases are needed to justify allowing particular roles in particular situations. Thankfully, this is not an especially burdensome bar; it is relatively trivial to describe use cases that exist. Furthermore, it is easy to loosen the rules as use cases are discovered over time; there is no rush to allow as much as possible as soon as possible.


''Note: a working group decision not to add the apparently arbitrary set of roles discussed in the above bugs should not be taken as a working group decision not to add specific roles in specific situations in the future, as use cases are put forward. Should a use case be provided for a particular combination, it should be considered on its own merits and added if appropriate. This change proposal merely argues against a wholesale addition of roles with little to no consideration of specific use cases, especially because a number of the combinations proposed are simply daft.''
''Note: a working group decision not to add the apparently arbitrary set of roles discussed in the above bugs should not be taken as a working group decision not to add specific roles in specific situations in the future, as use cases are put forward. Should a use case be provided for a particular combination, it should be considered on its own merits and added if appropriate. This change proposal merely argues against a wholesale addition of roles with little to no consideration of specific use cases, especially because a number of the combinations proposed are simply daft.''
Line 156: Line 162:
=== Negative effects ===
=== Negative effects ===


★‬
None. Specifically, two classes of changes are at stake here: editorial changes to the section on accessibility annotations, and normative changes to the integration with ARIA. This change proposal explains why the proposed editorial changes would be regression. Changes to the ARIA integration are not ruled out by this change proposal should appropriate use cases be brought forward, and there is no harm in applying prudence to this process.


=== Conformance Class Changes ===
=== Conformance Class Changes ===
Line 169: Line 175:
<references/>
<references/>


= Objections to the other change proposal =
''If there is objectionable material in the [http://www.w3.org/html/wg/wiki/ChangeProposals/ARIAinHTML5 other change proposal] that would be inappropriate to list in the above CP, then list it here so that it can be tracked and presented during the poll.''
== Process objections ==
* The discussion about changing the title or adding an introduction section seems out of scope for this issue, since it is already covered by issue 109, which has already gone to poll and is awaiting a chair response.
* The table added based on the arguments in the ''basis for addition of "WAI-ARIA and HTML5 Attributes" table'' section makes numerous changes that were never raised in any bug and that are not justified by any arguments in the change proposal.
* The ''HTML to Platform Accessibility APIs'' document, also referred to as the ''HTML to Platform Accessibility APIs Implementation Guide'' in this change proposal, should be considered out of scope as it was not proposed in any of the bugs resulting in this issue.
* The change proposal contains phrases in the rationale section that fail to provide justification or rationale for changes, and instead appear to merely describe the changes in incomplete sentences (e.g. "An attempt to provide clear advice to developers of user agents.", and "Leaving the content of the ARIA section of the HTML5 specification as normative for author conformance and informative for user agent and conformance checkers.").
* In general, this issue seems to have been raised in a manner contrary to the spirit of the working group process. No effort has been made to actually work with the working group to resolve issues or to explain the underlying problems. Numerous arguments presented in the change proposal are novel, having never been presented before (e.g. in bugs or public-html mailing list discussion). A number of the bugs escalated and contributing to this issue have consist of an incoherent bug description followed by an immediate escalation after the editor asked for further clarifications. At least one of the bugs was even escalated after the bug was resolved, without any attempt at conflict resolution.
== Objections to the rationale ==
=== Objections to the rationale's introduction  ===
* The rationale of this CP implies that requiring authors to violate the semantics of elements should be allowed, but this would lead to serious accessibility and data analysis failures, essentially missing the entire point of HTML's design philosophy for the past 20 years, and regressing us substantially to the days of "font" elements, single-pixel GIFs, and layout tables. This would be a disaster for accessibility, a disaster for advocacy, and would lead to such confusion amongst the developer community that we might easily lose a decade of pro-accessibility advocacy progress (historically, developers have reacted quite poorly to dramatic changes in the messaging on such topics).
* This CP claims that the specification provides tools for authors to violate the semantics of an element in the form of JS and CSS, but does not provide tools in the form of ARIA. However, this is false. The specification provides ARIA tools to violate semantics to the same extent as CSS and JS tools; it makes such violations non-conforming regardless of the technology used (CSS, JS, or ARIA). Therefore this is a false dichotomy: if an author finds it acceptable to violate the specification in one place, it stands to reason that violating the specification elsewhere would be considered no worse, and if an author does ''not'' violate the semantics using CSS and/or JS, then there's no need to use ARIA for this use either.
* ARIA markup happens to be one of the few ways we can programatically verify semantic consistency, and seriously relaxing, or indeed removing, the restrictions on how ARIA can be applied to HTML would cause us to largely, or completely, miss this opportunity to educate users to improve their site's accessibility. Furthermore, the specification details care that validators need to take in the messaging in this area to encourage authors to write better, more accessible markup, rather than having them just drop the ARIA — so the risks detailed in this CP have already been mitigated by the specification's current text.
* It is important for overall platform consistency that a platform's specifications take a holistic approach, considering all of the features as a whole rather than each one individually. This CP fails to take such an approach, instead treating ARIA markup as a special case to which basic design principles somehow do not apply. For instance, it is implicitly argued in the CP that authors writing HTML without ARIA are able to update their markup,  and this is contrasted to the case of an author writing HTML with ARIA where it is explicitly argued that the author cannot update any markup except ARIA markup. However, this is patently absurd: ARIA markup is just as much markup as the rest of HTML, so if one part of the document can be edited, so can the rest. Indeed, in conjunction with the aforementioned advice for validator implementors, it is more likely that authors will correct their non-ARIA markup than the ARIA annotations, since the validator is not expected to even mention ARIA in such situations.
* The rationale makes a number of false statements or implications. For instance, it refers to ARIA as an "accessibility repair method", which is inaccurate (the word "repair" indeed only appears once in the whole ARIA specification, in the context of images used for mathematics). The ARIA specification's abstract clearly delineates ARIA's role as being for describing "accessible user interface elements" that "can be used to improve the accessibility and interoperability of web content and applications": it is essentially and primarily for annotating "div" and "span" elements that are being used to create custom widgets. Another example of a false statement or implication in this CP is the assertion that the ARIA role taxonomy is designed so that children in that taxonomy can always be used in place of their parents. However, this is trivially disprovable by example: the "radio" role is a child of the "checkbox" role, yet these are not interchangeable native HTML concepts; similarly, the "listitem" role, which requires a "list" parent in the DOM, has as a child role the "treeitem" role, which requires a "group" or "tree" parent, so again these are clearly not interchangeable.
=== Objections to ''basis for addition the merging of the tables in the current spec text'' [sic] ===
* The premise that the current text does not define which roles, states, and properties can be used in which situations is flat-out incorrect. That is the bulk of the current section, and it is defined very precisely.
* No reasoning is provided for merging the list defining the strong native semantics and the list defining restrictions for elements without strong native semantics.
* Merging these tables results in confused conformance criteria; the subtlety of the current spec's requirement is lost. For example, compare the text in the current spec to the text in the proposed text when it comes to defining the requirements on an ''input element with a type attribute in the Number state''. The current spec text is straightforward. The proposed text in this CP is incoherent. This is, IMHO, a result of this misguided attempt at merging the tables.
=== Objections to ''basis for changes to command roles'' ===
★‬
=== Objections to ''basis for defining h1 to h6 element that does have an hgroup ancestor'' ===
The rationale begins by implying that there is ambiguity regarding the default role of elements that the specification does not mention explicitly in the accessibility tool annotations section, but there is no such ambiguity: the default for ''any'' element without strong native semantics or implied ARIA semantics is defined by the ARIA specification. The change proposal continues to state that it would be illogical for the specification to require that headings inside HGROUP elements be exposed to UAs in the same way as headings outside HGROUP elements, but this is a straw man argument, since the specification explicitly states that these two cases are not handled the same way, by excluding headings inside HGROUP elements from the normative conformance requirements that apply to headings in general.
The change proposal goes on to state that two adjacent H1 elements with no role should be handled by ARIA user agents in the same way as two adjacent SPAN elements, and says that this is bad. It would indeed be bad, were it true, because it would also imply that ARIA user agents would be unable to convey paragraph breaks! (P elements similarly have no role.) This is naturally quite absurd; indeed, if true even the proposed solution in the change proposal would be broken (consider an HGROUP with three child Hx elements). A number of arguments are predicated on this premise, and are therefore equally faulty.
This section also references the outline algorithm, but this is irrelevant to the discussion as the outline algorithm is orthogonal to the ARIA roles used on elements.
=== Objections to ''basis for changes to allowed roles on the a element'' ===
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.
=== Objections to ''basis for addition of "WAI-ARIA and HTML5 Attributes" table'' ===
This section argues that the spec leaves this undefined, but this is flat-out incorrect. It is defined very precisely.
Furthermore, the arguments in this section are inconsistent with the arguments in the earlier section which suggested that having one table was clearer. Quite contrary to the earlier arguments that suggested that the spec was to be simplified by merging the two tables, the change proposal ''actually'' just changes the split from a coherent separation of elements with strong native semantics and elements with looser constraints, to an apparently incoherent split with attributes listed in one table and then partly repeated in another, data duplicated in multiple cells, etc.
=== Objections to ''basis for the img elements deualt role being img'' [sic] ===
=== Objections to ''basis for addition of "Guidance for User Agents"'' ===
The change proposal claims that the current specification is not comprehensive, which is false; it also says that this is somehow mutually exclusive with having links, which is again false, and is trivially disprovable since the HTML specification already links to a number of WAI documents in the "recommended reading" section and normatively references both the "Accessible Rich Internet Applications (WAI-ARIA)" and "WAI-ARIA 1.0 User Agent Implementation Guide" documents at the very start of the accessibility annotations section. There is nothing special about these documents that require that they be treated in a manner different than the 100+ other references in the specification.
=== Objections to ''basis for allowing roles on heading elements (H1-H6)'' ===
★‬
=== Objections to ''basis for addition of "References"'' ===
★‬
=== Objections to ''Guiding factors for decisions on ARIA Role use'' ===
★‬
=== Objections to the ''Positive Effects'' section ===
The section claims that the specification as currently written deters authors from using ARIA, but this is not true — the specification includes text (which is even included in this change proposal's proposed replacement text!) to ensure that conformance checkers do not lay the blame with ARIA attribute usage.
The change proposal claims that the proposed changes will allow developers to use HTML validators to check ARIA conformance, but that misses the point. To check ARIA conformance, an author should use an ARIA validator. An HTML validator should check HTML conformance. The change proposal prevents that (as it in fact admits).
Finally, this section claims that the proposal will make authoring conformance requirements more closely match deployed content, implying that this is an improvement. However, it is quite the opposite. The goal of conformance requirements is not to reflect ''current'' practice, but to reflect ''best'' practice.
== Objections to the proposed text ==
=== Overview ===
* The proposed text contains internal contradictions. For example, it suggests that the "abbr" element has no default role, but then specifies that the "abbr" element (when defining a command) has, in certain cases, the "menuitem" role; it also simultaneously allows authors to use aria-* attributes only in manners allowed in the HTML spec, allows authors to use aria-* attributes in any manner allowed in the ARIA specs, and requires authors to not use the aria-* attributes in ways that conflict with certain requirements, leaving the exact conformance situation highly unclear.
* The proposed text either abuses RFC2119 or has bogus conformance statements (it's unclear which). For example, the text explicitly allows "conflicts" to make things "difficult for assistive technology" (presumably mis-use of RFC2119, since "conflicts" are obviously not a defined conformance class); it also in another paragraph allows authors to "need" to do something.
* The proposed text has redundant conformance requirements, for example it restricts how people may use ARIA features multiple times with subtly different phrasing, without explaining why the requirements are repeated or whether the subtle differences are intended or not. Another example is how it simultaneously has a generic rule regarding state attributes matching equivalent HTML attributes, and has explicit rules for specific attributes. Another example is that it requires support for both the entire ARIA specification and then explicitly requires support for a subset of that specification.
* It contradicts the ARIA specification. For example, for "abbr" elements it says any aria-* attribute is allowed, but the ARIA spec restricts which attributes are allowed based on the role.
* It doesn't use the terms defined by ARIA for the purposes required by this section. For example, the term "strong native semantics" is not used. This means the spec breaks the normative definition chain.
* It allows ARIA attributes that are redundant with HTML native features, despite this having been demonstrated to result in cargo-cult accessibility authoring, which is harmful to accessibility, as discussed in bug 11557 (http://www.w3.org/Bugs/Public/show_bug.cgi?id=11557).
=== The tables ===
* The proposed text supposedly alphabetises the elements to which roles, states, and properties can be applied. However, this is nonsensical:
** The list is not a list of element types, but a list of conditions that elements can find themselves in, so it makes no sense to alphabetise the list by element name (some of the rows don't have any element name at all!).
** The list's ordering was the only mechanism for resolving conflicts, by changing the order arbitrarily, this resolution mechanism is lost (leading to some of the problems listed in the overview above).
* The second table is simply wrong. Here are some examples (there are many more errors; these is just a sample):
** It refers to the disabled attribute rather than the disabled concept, so for example it requires aria-disabled="true" to be set on controls that are descendants of disabled FIELDSET elements.
** It requires that draggable="" be set on elements that are marked as aria-grabbed, even though you can drag elements that don't have the attribute and setting the attribute would affect the user interface in a potentially breaking manner.
** It requires that the aria-checked="" attribute match the ''default'' value of the checkedness of a checkbox element, rather than the ''current'' state.
** It disallows aria-multiselectable="false" even on INPUT type="email" elements where "false" is the only sane value.
** It uses terms like "match the state" or "match the value" without defining them.
** It requires that aria-autocomplete be set in a way that mirrors the autocomplete="" attribute, despite this contradicting ARIA requirements (aria-autocomplete="" is about author-provided autocompletion UI, not UA-provided UI; the UA obviously is responsible for making its UI accessible, not the author!), and despite this being harmful to accessibility even if it didn't contradict ARIA (since it would mean that any UA with unusual autocompletion UI would be inaccessible on pages that followed the rules given in the proposal).
=== The ''Guidance for User Agents'' section ===
There is nothing of use in this section. All the requirements and statements are redundant statements repeating requirements or statements from elsewhere in the HTML and ARIA specifications. All it serves to do is lengthen the specification and potentially confuse readers.
==== The ''HTML to Platform Accessibility APIs Implementation Guide'' ====
''The change proposal surreptitiously includes an entire extra document which it mentions in passing should possibly be an appendix to the specification. The paragraphs below summarise objections to that document.''
This document contains requirements that are redundant with the HTML, ARIA, and ARIAIMPL specifications. Having specifications state redundant requirements is very poor form for specification writing, as it leads to unintended ambiguities (where different specifications unintentionally state things slightly differently), and thus interoperability failures. Implementors and advocates who are not fully engaged with the standards process are likely to try to find meaning in the unintended differences, with often quite unexpected conclusions (just look at the folklore that has sprung up around the spelling of the specification's name — is there a space between the "HTML" and the "5" or not? Entire yarns of pseudo-history have been spun around this question). These problems can be especially pernicious because to advocate that an implementor who follows one spec should instead follow the other requires more than the usual standards-compliance advocacy (and indeed, can be at odds with that advocacy, since it requires violating one spec to follow the other).
Furthermore, not only is the proposed document redundant, it is both incomplete and inaccurate. As currently written it presents a dramatically oversimplified view of the requirements on implementations, but even as currently written it does not claim to be complete, with numerous holes, an entire "To Do" section, and question marks throughout.


In fact, the proposed document is unnecessary. Vendors have not shown an inability to read the existing normative specifications, and the text does not help authors or readers of the specification. While it would be fine for the working group to publish a note of this kind (with suitable disclaimers), it is inappropriate as an addition to the specification itself.
[[Category:W3C Issue]]

Latest revision as of 03:05, 16 June 2011

Summary

Don't allow people to use ARIA to write inaccessible documents.

Rationale

The bug titles given below are intended to describe the actual underlying requests or issues raised in the bugs. They do not match the original bug summaries as those were often quite misleading when compared to the actual requests.

General points

The current section defining the relationship between the HTML and ARIA specifications uses an approach eminently suited for addressing accessibility in HTML. It is defined in terms that the ARIA specification uses, provides the information needed by implementors, authors, and validator writers, and provides a coherent and concise set of UA and document requirements.

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. The current specification text achieves this: it 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" [1], disallowing ARIA markup that does not make sense, and allowing markup that does. It does not allow overrides of widget roles by unrelated widget roles, or allow overrides of semantic roles by unrelated semantic roles, nor does it allow for overriding of aspects of elements. It allows roles to be overridden by their children in the ARIA role taxonomy where that makes sense, and disallows it where it does not. (The role taxonomy in ARIA is based on a role's features; it does not follow that children are always more specific versions of the same concept. For instance, menuitemradio and menuitemcheckbox are not interchangeable in user interfaces, but in ARIA the former is a child of the latter.)

Bug 10444: Requesting a list of all the elements that do not have a default ARIA role

Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10444

  • There's no clear use case for this. Implementors wouldn't benefit (no default role would just be the overall default, so there's no need to list out which specific cases it should apply to). Authors wouldn't benefit (the section is listing restrictions, it's self-evident that anything that isn't restricted is unrestricted). Validators wouldn't benefit (there's nothing to implement if it's not a restriction).
  • An accurate list would be confusing to authors. For example, for each element one would have to explicitly list that it does have a role if the accesskey is set with a valid value that the user agent was able to apply, etc. For elements that have roles in specific situations, like H1 which only has a role when it's not in an HGROUP, or INPUT elements which only have roles when their TYPE attribute is in particular states, the situation is even worse, because the list would have to give all the conditions not matched by the elements when the do have a role. Thus, the list would be extremely opaque and would not be helpful to authors — indeed on the contrary, it would lead authors to thinking the situation was far more complicated than it really is, potentially leading to them not using the features at all, which could conceivably harm accessibility.
  • An accurate list would be incredibly hard to maintain, because of the complexities described in the previous point. No accurate list has been put forward; the only attempts at making such a list so far have been either vague or woefully inaccurate.
  • Even a vague list would be hard to maintain. We actually had a vague non-normative list in the spec for a while, but ended up removing it from the spec because of the maintenance nightmare that it spawned (the list kept having to be updated because errors kept being found — and that was just with a non-normative vague list).
  • Confusion stemming from the inevitable inaccuracies listed in the previous points will likely lead to implementation mistakes, leading to poor interoperability, which would harm accessibility (since this is an accessibility feature).

Summary: no use cases, maintenance nightmare, might even harm accessibility.

Bug 10462: Merge the table defining strong native semantics and the table listing role and state constraints into a single table

Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10462

Providing unclear or ambiguous guidance to authors about how ARIA can be used in HTML5 is likely to negatively impact the correct use of ARIA on the Web. Indeed, failing to provide such information does a disservice to both Web developers, who author ARIA-supporting applications, and to users with disabilities, who rely on those annotations to make use of those applications.

Therefore, it is imperative that the information provided be structured coherently, be compatible with ARIA terminology, and be correct. To this end, it is important that elements with strong native semantics be specified separately from elements with mere defaults and some constraints, and that both sets of requirements be properly introduced with RFC2119 and ARIA terminology. This is what is done in the specification as it stands today; in part, this is done by keeping the tables separate.

Summary: keeping the tables separate is key to maintaining the clarity of the specification.

Bug 10603: Confusion arising from an earlier attempt at resolving the aforementioned bugs

Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10603

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.

Summary: issue seems to already be resolved.

Bugs 8000 and 10448: Allow links to be described as scroll bars, buttons to be described as progress bars, etc

Bugs: http://www.w3.org/Bugs/Public/show_bug.cgi?id=8000; http://www.w3.org/Bugs/Public/show_bug.cgi?id=10448

The two bugs are more or less duplicates of each other.

No use cases have been provided to explain the benefit of allowing links to be described as scroll bars, buttons to be described as progress bars, and so forth, despite repeated requests for use cases.

It has been suggested that occurrences of the following need role="button" to be made accessible:

  <a href="#" onclick="action()">...</a>
  <a href="javascript:action()">...</a>

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. They are not syntactically non-conforming because they both have valid use cases in indistinguishable cases: <a href="javascript:"> is needed to expose bookmarklets to users, and onclick="" is needed for a wide variety of interactive purposes even on normal links (e.g. making AJAX applications gracefully degrade). Even a link to href="#" has some use cases, e.g. to link to the current page to provide the user with a draggable URL for bookmarking purposes. There's no reason such links shouldn't be made interactive (e.g. the onclick="" could just trigger a click animation). So we can't catch this particular case with a validator. It's unfortunate, but that's what happens when there are valid use cases.

The role="" attribute gives us the unique opportunity to catch this particular error as a syntax error. This is a good thing, not a problem.

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.

ARIA is useful for authors who need to make new widgets that HTML doesn't yet support. Buttons are supported by HTML, and therefore there is no reason for an author to make a link act like a button to ATs.

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.

What's important to remember is that there are more than two kinds of user agents; there are at least three:

  1. User agents with scripting, CSS, etc, which can be made to render elements (like <a>) as other elements (like <button>).
  2. User agents with ATs, which report the accessibility mapping described with ARIA, defaulting to the default semantics of the elements.
  3. User agents without CSS support or without scripting support, and certainly without ATs, which always use the default semantics of the elements.

Some examples of #3 are the text-based browsers, most search engines, and graphical browsers in which CSS or scripting are disabled.

The only way to keep things consistent amongst all three is to use HTML elements appropriately, and not override their semantics with ARIA.

ARIA is great when you're creating new widgets that aren't in HTML yet: it allows you to create pages that work in #1 and #2, covering the vast majority of users, at the cost of #3, who wouldn't be able to experience the new widget at all anyway. However, when HTML provides the widget you need, as in the case of a button or a link, and #3 already supports that widget and therefore there is no need to fake it. In these cases, ARIA is unsuitable and unnecessary. Validators flag the use of ARIA in these ways, since there is a net benefit to using appropriate elements instead of ARIA in those cases.

See also the section below explaining why use cases are necessary for such features.

Summary: no valid use cases presented; some specific cases would even harm overall accessibility of the Web.

Bug 10449: Allow an H1 element to be described as a spinbutton or checkbox, etc

Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10449

No use cases have been provided to explain the benefit of allowing headings to be described as spinbuttons, checkboxes, and so forth, despite repeated requests for use cases.

In the absence of concrete use cases, and given the preposterousness of using an element whose semantic is "heading" to mark up a checkbox or scrollbar, of all things, it would do authors a disservice not to flag such questionable cases.

See also the section below explaining why use cases are necessary for such features.

Summary: no use cases.

Bug 10481: Set the default role of IMG elements to ARIA's "img" value

Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10481

For most images, role=img is unsuitable, because the IMG element's main purpose (from the point of view of an AT user) is not to convey an image, but to convey text. For example, an image as part of a link conveys information about the link. An image of a company logo conveys the name of a company. An image of social networking site conveys the name of that site. Informally, if one browses the Web one will quickly find that most images are either presentational (alt=""), logos, text in buttons or links, or icons. Very few are actually interesting from the point of view of conveying actual graphical information. Even on pages where one would think there were interesting images, they are in the minority — for example, the Flickr page for a photograph has on the order of 20 images only one of which is really an image from the AT user's perspective.

Using role=img for an IMG element is therefore likely to lead to a relatively poor user experience. Rather than getting on with the job of letting the user interact with the page, an AT user would be constantly reminded that the page is full of images, something which a non-AT user would never think of.

It is sometimes argued that the reason role=img is supposedly necessary is that without it, image-specific user interface commands, e.g. to view the image in a separate tab, or to obtain the image's dimensions or URL, would be unavailable. However, such behaviour would be nonsensical. A user may still wish to interact with a presentational image (with role=presentational, not role=img), and a non-IMG element (e.g. DIV) with role=img would not get image-specific user interface commands (those commands would be meaningless). The two issues are thus obviously orthogonal. role=img only controls how the element is presented by the AT by default; it should not prevent users from interacting with images as images if they so desire.

Summary: 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.

Bug 10493: Requesting additional prose in the HTML spec stating that certain roles defined in the ARIA spec have restrictions on their use defined in the ARIA spec

Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10493

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. Having redundant text courts mistakes (as the original text presumably demonstrated, assuming the proposed correction was itself correct), which then results in reader confusion and, in the worst case, interoperability inconsistencies as different implementations interpret each implied instruction independently.

Summary: suggested clarification is out of scope for the specification.

Bug 10592: Request regarding the ARIA role of heading elements inside HGROUP elements

Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10592

The intent of this bug is assumed to be as described above based on the arguments presented in this issue's other change proposal. The bug itself has an incoherent request, does not state a problem, and was never clarified despite a request by the editor.

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 means setting the "heading" role on the HGROUP element, and treating the Hx elements in the HGROUP element the same way as paragraphs are treated normally.

Summary: what the spec requires is the appropriate set of roles for this situation.

Bug 10594: Move some requirements regarding ARIA attributes into a separate table

Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10594

The description of this bug listed above is derived from the other change proposal for this issue; unfortunately neither the bug nor the other change proposal included enough detail to provide an accurate rational description of the request.

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.

We should, indeed, include detailed requirements regarding the constraints placed on ARIA attributes in different situations. For example, it is important that the aria-disabled="" attribute be set to "true" on any control that is disabled (not any control that has the disabled="" attribute specified, which is a different matter). It is important that we restrict aria-valuemax="" when set on INPUT elements in the Range state to the maximum value (not necessarily the value given in the max="" attribute). There are a number of such requirements. The specification requires all the ones that make sense.

Summary: what the spec says is already what is appropriate for these requirements.

Bug 10903: Requesting more introductory text

Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10903

This is out of scope for this issue since it is already a part of ISSUE-109, which has already been taken to poll.

Summary: out of scope.

Why use cases are needed to justify allowing particular roles in particular situations

Using a role in a particular situation is either reasonable, on unreasonable. For example, labeling list items (LI elements) as role="treeitem" is reasonable, since one can use nested lists to create trees without violating any semantics (a tree can in fact be described as a structure of nested lists). On the other hand, labeling a list item as a role="heading" is unreasonable, because there is no need for it and thus occurrences of such markup are highly likely to be indicative of either underlying semantic misuse (which can lead to usability problems in non-AT non-CSS/JS UAs, processing problems in markup analysis tools like search engines, maintenance difficulties, etc), or of unintentional markup errors (for which authors would benefit from validators and other QA tools flagging the problem).

Thus, to craft the conformance criteria for HTML's use of ARIA, we have to figure out what features fall into the "reasonable" camp and which fall into the "unreasonable" camp. (This is supported by ARIA itself, which provides hooks for markup languages to use to indicate exactly this categorisation — that's the whole point of having "strong native semantics", which is one of the main things the accessibility annotations section defines.) To do this in a consistent way, the main tool we have at our disposal is the consideration of use cases. This is why use cases are needed to justify allowing particular roles in particular situations. Thankfully, this is not an especially burdensome bar; it is relatively trivial to describe use cases that exist. Furthermore, it is easy to loosen the rules as use cases are discovered over time; there is no rush to allow as much as possible as soon as possible.

Note: a working group decision not to add the apparently arbitrary set of roles discussed in the above bugs should not be taken as a working group decision not to add specific roles in specific situations in the future, as use cases are put forward. Should a use case be provided for a particular combination, it should be considered on its own merits and added if appropriate. This change proposal merely argues against a wholesale addition of roles with little to no consideration of specific use cases, especially because a number of the combinations proposed are simply daft.

Details

Change nothing.

Impact

Positive effects

  • Keeps the specification clear.
  • Encourages authors to use HTML as intended, which increases the total accessibility of the Web.
  • Allows authors to check both HTML validity (with an HTML validator), catching errors such as using a BUTTON element where an A element would be more appropriate and more accessible; and ARIA validity (with an ARIA validator), catching errors where ARIA attributes are used incorrectly (regardless of the validity of the underlying markup, and indeed regardless of its vocabulary — HTML, SVG, MathML, or even a custom language).

Negative effects

None. Specifically, two classes of changes are at stake here: editorial changes to the section on accessibility annotations, and normative changes to the integration with ARIA. This change proposal explains why the proposed editorial changes would be regression. Changes to the ARIA integration are not ruled out by this change proposal should appropriate use cases be brought forward, and there is no harm in applying prudence to this process.

Conformance Class Changes

None.

Risks

Including the ARIA section at all might encourage authors to create more custom widgets. Given the limitations of ARIA and the limitations of most Web authors in wielding tools such as ARIA, it is likely that this would lead to an overall reduction in the accessibility of the Web. Since very few features expressible in ARIA are still not expressible in native HTML, it might be better for the platform as a whole to simply provide the widgets that authors need rather than having them create them manually with bolt-on accessibility provided courtesy of ARIA attributes.

References