Change Proposal for ISSUE-129 - Revision history

Hixie at 03:05, 16 June 2011

2011-06-16T03:05:38Z

← Older revision		Revision as of 03:05, 16 June 2011
Line 174:		Line 174:

	<references/>		<references/>


			[[Category:W3C Issue]]

Hixie at 04:07, 19 January 2011

2011-01-19T04:07:14Z

← Older revision		Revision as of 04:07, 19 January 2011
Line 13:		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 53:		Line 53:
	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>

Hixie: /* Rationale */

2011-01-17T09:56:28Z

Rationale

Hixie: /* Bug 10903: Requesting more introductory text */

2011-01-17T09:55:40Z

Bug 10903: Requesting more introductory text

← Older revision		Revision as of 09:55, 17 January 2011
Line 139:		Line 139:
	This is out of scope for this issue since it is already a part of ISSUE-109, which has already been taken to poll.		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.'''		'''Summary: Out of scope.'''

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

Hixie: /* Objections to the other change proposal */

2011-01-17T09:55:08Z

Objections to the other change proposal

← Older revision		Revision as of 09:55, 17 January 2011
Line 174:		Line 174:

	<references/>		<references/>

	~~= Objections to the other change proposal =~~

	~~See [[Objections against CP for ISSUE-129]].~~

Hixie: /* Bug 10903: Requesting more introductory text */

2011-01-17T09:35:29Z

Bug 10903: Requesting more introductory text

← Older revision		Revision as of 09:35, 17 January 2011
Line 138:		Line 138:

	This is out of scope for this issue since it is already a part of ISSUE-109, which has already been taken to poll.		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 ===		=== Why use cases are needed to justify allowing particular roles in particular situations ===

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

2011-01-17T09:35:13Z

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

← Older revision		Revision as of 09:35, 17 January 2011
Line 131:		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: '''~~-->~~
			'''Summary: What the spec says is already what is appropriate for these requirements.'''

	=== Bug 10903: Requesting more introductory text ===		=== Bug 10903: Requesting more introductory text ===

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

2011-01-17T09:32:30Z

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

← Older revision		Revision as of 09:32, 17 January 2011
Line 120:		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 ===

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

2011-01-17T00:51:40Z

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

← Older revision		Revision as of 00:51, 17 January 2011
Line 87:		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.''

Hixie: /* Why use cases are needed to justify allowing particular roles in particular situations */

2011-01-16T08:27:54Z

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

← Older revision		Revision as of 08:27, 16 January 2011
Line 141:		Line 141:
	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).		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.) 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.		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.''

← Older revision		Revision as of 09:56, 17 January 2011
Line 44:		Line 44:
	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.		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.'''		'''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 8000 and 10448: Allow links to be described as scroll bars, buttons to be described as progress bars, etc ===
Line 105:		Line 105:
	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.		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.'''		'''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 ===
Line 112:		Line 112:
	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.		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.'''		'''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 121:		Line 121:
	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: ~~What~~ the spec requires is the appropriate set of roles for this situation.'''		'''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 132:		Line 132:
	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: ~~What~~ the spec says is already what is appropriate for these requirements.'''		'''Summary: what the spec says is already what is appropriate for these requirements.'''

	=== Bug 10903: Requesting more introductory text ===		=== Bug 10903: Requesting more introductory text ===
Line 139:		Line 139:
	This is out of scope for this issue since it is already a part of ISSUE-109, which has already been taken to poll.		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.'''		'''Summary: out of scope.'''

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