Objections against CP for ISSUE-129 - Revision history

Hixie at 03:05, 16 June 2011

2011-06-16T03:05:32Z

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

	See [[Change Proposal for ISSUE-129]].		See [[Change Proposal for ISSUE-129]].


			[[Category:W3C Issue]]

Hixie at 20:35, 9 February 2011

2011-02-09T20:35:10Z

Hixie: /* Objections to the proposed text */

2011-02-09T20:32:53Z

Objections to the proposed text

@@ Line 82: / Line 82: @@
 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.
 = Counter Change Proposal =
 See [[Change Proposal for ISSUE-129]].

Hixie: /* Objections to Guiding factors for decisions on ARIA Role use */

2011-02-09T20:31:10Z

Objections to Guiding factors for decisions on ARIA Role use

← Older revision		Revision as of 20:31, 9 February 2011
Line 73:		Line 73:
	=== Objections to ''Guiding factors for decisions on ARIA Role use'' ===		=== Objections to ''Guiding factors for decisions on ARIA Role use'' ===

	This section consists of nothing but assertions without rationales.		This section consists of nothing but assertions without rationales. I disagree with many if not all of these assertions; they should not be considered uncontested, merely unsubstantiated.

	=== Objections to the ''Positive Effects'' section ===		=== Objections to the ''Positive Effects'' section ===

Hixie: /* Objections to basis for addition of "References" */

2011-02-09T20:27:12Z

Objections to basis for addition of "References"

← Older revision		Revision as of 20:27, 9 February 2011
Line 70:		Line 70:

	Finally, this section provides an example where a heading, which in the graphical representation looks like a heading, acts like a heading, and gives no indication of being anything but a heading, happens to have an onclick="" handler. It is subsequently argued that in ATs, this heading should in fact appear to be a button. However, that would be quite confusing to any AT user. For example, should a friend of the reader's refer to the heading as a heading, the AT user would have no way to know which heading their friend was referring to. The heading in this example isn't a button. Exposing it as a button to ATs would be a bug.		Finally, this section provides an example where a heading, which in the graphical representation looks like a heading, acts like a heading, and gives no indication of being anything but a heading, happens to have an onclick="" handler. It is subsequently argued that in ATs, this heading should in fact appear to be a button. However, that would be quite confusing to any AT user. For example, should a friend of the reader's refer to the heading as a heading, the AT user would have no way to know which heading their friend was referring to. The heading in this example isn't a button. Exposing it as a button to ATs would be a bug.

	~~=== Objections to ''basis for addition of "References"'' ===~~

	Adding a subsection for references makes no sense since the specification already has an entire section for references. There's nothing special about these specific documents that means they should get their own separate references section.

	=== Objections to ''Guiding factors for decisions on ARIA Role use'' ===		=== Objections to ''Guiding factors for decisions on ARIA Role use'' ===

Hixie: /* Objections to basis for addition of "Guidance for User Agents" */

2011-02-09T20:25:32Z

Objections to basis for addition of "Guidance for User Agents"

← Older revision		Revision as of 20:25, 9 February 2011
Line 62:		Line 62:

	Even without role=img, a user should still be able to tell his UA and AT to zoom into images on the page. If only role=img allowed this, then the user wouldn't be able to zoom into background images, images used as buttons ("input type=image"), images used a list bullets, etc. Quite obviously, this would be a bug in the UA/AT. If the specification's current requirements broke ATs, then the ATs would be broken already in numerous cases where role=img does not, and cannot, apply to an image (e.g. any image in CSS).		Even without role=img, a user should still be able to tell his UA and AT to zoom into images on the page. If only role=img allowed this, then the user wouldn't be able to zoom into background images, images used as buttons ("input type=image"), images used a list bullets, etc. Quite obviously, this would be a bug in the UA/AT. If the specification's current requirements broke ATs, then the ATs would be broken already in numerous cases where role=img does not, and cannot, apply to an image (e.g. any image in CSS).

	~~=== 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 allowing roles on heading elements (H1-H6)'' ===

Hixie: /* Objections to basis for the img elements defualt role being img [sic] */

2011-02-09T20:25:11Z

Objections to basis for the img elements defualt role being img [sic]

← Older revision		Revision as of 20:25, 9 February 2011
Line 60:		Line 60:

	It is true that we should not mandate UI for any user agents — and the role="" attribute does not. Mapping or not mapping an element to role="img" does deny ATs "the ability to offer users a preference about what role information they can receive"; if it did, then we would be mandating UI, which we should not, just as the CP says.		It is true that we should not mandate UI for any user agents — and the role="" attribute does not. Mapping or not mapping an element to role="img" does deny ATs "the ability to offer users a preference about what role information they can receive"; if it did, then we would be mandating UI, which we should not, just as the CP says.

			Even without role=img, a user should still be able to tell his UA and AT to zoom into images on the page. If only role=img allowed this, then the user wouldn't be able to zoom into background images, images used as buttons ("input type=image"), images used a list bullets, etc. Quite obviously, this would be a bug in the UA/AT. If the specification's current requirements broke ATs, then the ATs would be broken already in numerous cases where role=img does not, and cannot, apply to an image (e.g. any image in CSS).

	=== Objections to ''basis for addition of "Guidance for User Agents"'' ===		=== Objections to ''basis for addition of "Guidance for User Agents"'' ===

Hixie: /* Objections to basis for the img elements deualt role being img [sic] */

2011-02-09T20:21:06Z

Objections to basis for the img elements deualt role being img [sic]

← Older revision		Revision as of 20:21, 9 February 2011
Line 57:		Line 57:
	Finally, the CP in this section repeats the assertion that HTML's authoring conformance criteria in one section will be ignored, and that therefore conformance criteria in another section must be loosened to allow authors to work around their mistakes. This is self-contradictory. Either authors will follow the spec, in which case they won't need to the loosened requirements proposed, or they won't, in which case the entire discussion is moot since authors will ignore both the ARIA-related conformance criteria ''and'' the more fundamental requirements related to correct use of elements.		Finally, the CP in this section repeats the assertion that HTML's authoring conformance criteria in one section will be ignored, and that therefore conformance criteria in another section must be loosened to allow authors to work around their mistakes. This is self-contradictory. Either authors will follow the spec, in which case they won't need to the loosened requirements proposed, or they won't, in which case the entire discussion is moot since authors will ignore both the ARIA-related conformance criteria ''and'' the more fundamental requirements related to correct use of elements.

	=== Objections to ''basis for the img elements ~~deualt~~ role being img'' [sic] ===		=== Objections to ''basis for the img elements defualt role being img'' [sic] ===

	It is true that we should not mandate UI for any user agents — and the role="" attribute does not. Mapping or not mapping an element to role="img" does deny ATs "the ability to offer users a preference about what role information they can receive"; if it did, then we would be mandating UI, which we should not, just as the CP says.		It is true that we should not mandate UI for any user agents — and the role="" attribute does not. Mapping or not mapping an element to role="img" does deny ATs "the ability to offer users a preference about what role information they can receive"; if it did, then we would be mandating UI, which we should not, just as the CP says.

Hixie: /* Objections to basis for addition of "WAI-ARIA and HTML5 Attributes" table */

2011-02-09T20:20:32Z

Objections to basis for addition of "WAI-ARIA and HTML5 Attributes" table

← Older revision		Revision as of 20:20, 9 February 2011
Line 56:		Line 56:

	Finally, the CP in this section repeats the assertion that HTML's authoring conformance criteria in one section will be ignored, and that therefore conformance criteria in another section must be loosened to allow authors to work around their mistakes. This is self-contradictory. Either authors will follow the spec, in which case they won't need to the loosened requirements proposed, or they won't, in which case the entire discussion is moot since authors will ignore both the ARIA-related conformance criteria ''and'' the more fundamental requirements related to correct use of elements.		Finally, the CP in this section repeats the assertion that HTML's authoring conformance criteria in one section will be ignored, and that therefore conformance criteria in another section must be loosened to allow authors to work around their mistakes. This is self-contradictory. Either authors will follow the spec, in which case they won't need to the loosened requirements proposed, or they won't, in which case the entire discussion is moot since authors will ignore both the ARIA-related conformance criteria ''and'' the more fundamental requirements related to correct use of elements.

	~~=== 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 the img elements deualt role being img'' [sic] ===

Hixie: /* Objections to basis for changes to allowed roles on the a element */

2011-02-09T20:19:38Z

Objections to basis for changes to allowed roles on the a element

← Older revision		Revision as of 20:19, 9 February 2011
Line 50:		Line 50:
	;http://www.jstree.com/demo		;http://www.jstree.com/demo
	:Using links for this semantic is again a misuse of HTML. The "div" element is the appropriate element to use for creating widgets of this nature.		:Using links for this semantic is again a misuse of HTML. The "div" element is the appropriate element to use for creating widgets of this nature.
			;GMail's buttons made from links
			:GMail mostly uses "div"s for its buttons, but in any case the CP is correct: GMail should not use links for buttons.

			The CP goes on to admit that the "a" element isn't necessary for these use cases, and that "div" will work fine. But it then says that the change to the HTML5 spec is needed to work around the lack of a fix to the ''HTML4'' spec; a fix that has already been applied to the HTML5 spec (and thus would take effect at the same time as the workaround, and no later) and that has already been widely implemented.

			Finally, the CP in this section repeats the assertion that HTML's authoring conformance criteria in one section will be ignored, and that therefore conformance criteria in another section must be loosened to allow authors to work around their mistakes. This is self-contradictory. Either authors will follow the spec, in which case they won't need to the loosened requirements proposed, or they won't, in which case the entire discussion is moot since authors will ignore both the ARIA-related conformance criteria ''and'' the more fundamental requirements related to correct use of elements.

	=== Objections to ''basis for addition of "WAI-ARIA and HTML5 Attributes" table'' ===		=== Objections to ''basis for addition of "WAI-ARIA and HTML5 Attributes" table'' ===

← Older revision		Revision as of 20:35, 9 February 2011
Line 5:		Line 5:
	=== Objections to the rationale's introduction ===		=== 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).		* 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.		* 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.		* 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.		* 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.
Line 18:		Line 18:
	=== Objections to ''basis for defining h1 to h6 element that does have an hgroup ancestor'' ===		=== 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 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 P elements, and that this is bad. However, in practice this is quite harmless; indeed, when reading a book title and subtitle one does not distinguish them other than by a pause between them ("The Reality Dysfunction. Space is not the only void.").		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 P elements, and that this is bad. However, in practice this is quite harmless; indeed, when reading a book title and subtitle one does not distinguish them other than by a pause between them ("The Reality Dysfunction. Space is not the only void.").
Line 28:		Line 28:
	=== Objections to ''basis for changes to allowed roles on the a element'' ===		=== 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 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.		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.
Line 45:		Line 45:
	:Again, there does not appear to be any ARIA on this page, but in any case it's not clear that any role other than menuitem="" would be appropriate for the items in this menu. (menuitem="" is the role the HTML spec would enforce on pages that marked this up correctly using the "menu" and "a" elements.)		:Again, there does not appear to be any ARIA on this page, but in any case it's not clear that any role other than menuitem="" would be appropriate for the items in this menu. (menuitem="" is the role the HTML spec would enforce on pages that marked this up correctly using the "menu" and "a" elements.)
	;http://jqueryui.com/demos/slider/		;http://jqueryui.com/demos/slider/
	:It would be quite inappropriate for the demo on this page to use a ~~''link''~~ for its UI (the tabindex="" attribute in conjunction with a "div" would be much more appropriate). In any case HTML already provides for this semantic natively ("input type=range").		:It would be quite inappropriate for the demo on this page to use a _link_ for its UI (the tabindex="" attribute in conjunction with a "div" would be much more appropriate). In any case HTML already provides for this semantic natively ("input type=range").
	;http://masinter.blogspot.com/		;http://masinter.blogspot.com/
	:HTML already provides checkboxes; using links for that semantic is a misuse of HTML.		:HTML already provides checkboxes; using links for that semantic is a misuse of HTML.
Line 53:		Line 53:
	:GMail mostly uses "div"s for its buttons, but in any case the CP is correct: GMail should not use links for buttons.		:GMail mostly uses "div"s for its buttons, but in any case the CP is correct: GMail should not use links for buttons.

	The CP goes on to admit that the "a" element isn't necessary for these use cases, and that "div" will work fine. But it then says that the change to the HTML5 spec is needed to work around the lack of a fix to the ~~''HTML4''~~ spec; a fix that has already been applied to the HTML5 spec (and thus would take effect at the same time as the workaround, and no later) and that has already been widely implemented.		The CP goes on to admit that the "a" element isn't necessary for these use cases, and that "div" will work fine. But it then says that the change to the HTML5 spec is needed to work around the lack of a fix to the _HTML4_ spec; a fix that has already been applied to the HTML5 spec (and thus would take effect at the same time as the workaround, and no later) and that has already been widely implemented.

	Finally, the CP in this section repeats the assertion that HTML's authoring conformance criteria in one section will be ignored, and that therefore conformance criteria in another section must be loosened to allow authors to work around their mistakes. This is self-contradictory. Either authors will follow the spec, in which case they won't need to the loosened requirements proposed, or they won't, in which case the entire discussion is moot since authors will ignore both the ARIA-related conformance criteria ~~''and''~~ the more fundamental requirements related to correct use of elements.		Finally, the CP in this section repeats the assertion that HTML's authoring conformance criteria in one section will be ignored, and that therefore conformance criteria in another section must be loosened to allow authors to work around their mistakes. This is self-contradictory. Either authors will follow the spec, in which case they won't need to the loosened requirements proposed, or they won't, in which case the entire discussion is moot since authors will ignore both the ARIA-related conformance criteria _and_ the more fundamental requirements related to correct use of elements.

	=== Objections to ''basis for the img elements defualt role being img'' [sic] ===		=== Objections to ''basis for the img elements defualt role being img'' [sic] ===
Line 81:		Line 81:
	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).		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.		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.

	= Counter Change Proposal =		= Counter Change Proposal =

	See [[Change Proposal for ISSUE-129]].		See [[Change Proposal for ISSUE-129]].