- From: Janina Sajka <janina@rednote.net>
- Date: Tue, 15 Dec 2009 00:33:52 +0000 (GMT)
- To: Henri Sivonen <hsivonen@iki.fi>
- CC: PFWG Public Comments <public-pfwg-comments@w3.org>
Dear Henri Sivonen:
Thank you for your comments on the 24 February 2009 Last Call Working
Draft of Accessible Rich Internet Applications (WAI-ARIA) 1.0
(http://www.w3.org/TR/2009/WD-wai-aria-20090224/). The Protocols and
Formats Working Group has reviewed all comments received on the draft. We
would like to know whether we have understood your comments correctly and
whether you are satisfied with our resolutions.
Please review our resolutions for the following comments, and reply to us
by 1 February 2010 to say whether you accept them or to discuss additional
concerns you have with our response. You can respond in the following
ways:
* If you have a W3C account, we request that you respond online at
http://www.w3.org/WAI/PF/comments/acknowledge?document_version_id=1;
* Else, by email to public-pfwg-comments@w3.org (be sure to reference our
comment ID so we can track your response). Note that this list is publicly
archived.
Please see below for the text of comments that you submitted and our
resolutions to your comments. Each comment includes a link to the archived
copy of your original comment on
http://lists.w3.org/Archives/Public/public-pfwg-comments/, and may also
include links to the relevant changes in the Accessible Rich Internet
Applications (WAI-ARIA) 1.0 editors' draft at
http://www.w3.org/WAI/PF/aria/20091214/.
Due to the scope of changes made in response to comments on the Last Call
Working Draft of WAI-ARIA, we are returning the specification to Working
Draft status. We will shortly publish a public "stabilization draft" of
WAI-ARIA and updated Working Drafts of the accompanying documents. While
these versions will not incorporate further discussion based on your
acknowledgement of our response to your comments, we will work with you on
your feedback as part of our preparation for the following version. You are
also welcome to submit new comments on the new public versions in addition
to sending your acknowledgement of our response to your previous comments.
Note that if you still strongly disagree with our resolution on an issue,
you have the opportunity to file a formal objection (according to 3.3.2 of
the W3C Process, at
http://www.w3.org/2005/10/Process-20051014/policies.html#WGArchiveMinorityViews)
to public-pfwg-comments@w3.org. Formal objections will be reviewed during
the candidate recommendation transition meeting with the W3C Director,
unless we can come to agreement with you on a resolution in advance of the
meeting.
Thank you for your time reviewing and sending comments. Though we cannot
always do exactly what each commenter requests, all of the comments are
valuable to the development of Accessible Rich Internet Applications
(WAI-ARIA) 1.0.
Regards,
Janina Sajka, PFWG Chair
Michael Cooper, PFWG Staff Contact
Comment 26: aria-valuenow index base into list of labels unclear
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0016.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-valuenow (property) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-valuenow>
Status: Accepted proposal
-------------
Your comment:
-------------
It would help if after the sentence "If the range is a set of qualitative
string values, such as "small", "medium", and "large", then aria-valuenow
is an index that chooses one of the set." it were pointed out that the base
of the index (Pascalesque 1, not conventional 0) is given in the definition
of aria-valuetext.
Furthermore, the definition of aria-valuetext should define the base index
using proper normative phrasing instead of letting the reader infer this
from an example.
http://www.w3.org/TR/wai-aria/#aria-valuenow
http://www.w3.org/TR/wai-aria/#aria-valuetext
--------------------------------
Response from the Working Group:
--------------------------------
Within the ARIA specification we do not want to make a formal requirement
that the index be 1-based, we have agreed in the Best Practices Guide to
suggest that to authors. This change is not yet in place but we expect it
to be in place in the next public draft. This is our ACTION-460.
----------------------------------------------------------------------
Comment 28: Should say that aria-valuemin must be less than or equal to aria-valuemax
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0018.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-valuemin (property) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-valuemin>
Status: Accepted proposal
-------------
Your comment:
-------------
My feedback previously given at
http://lists.w3.org/Archives/Public/public-pfwg-comments/2008JanMar/0042.html
was addressed only partially.
The spec still doesn't state an authoring requirement that the value of
aria-valuemin must be less than or equal to value of aria-valuemax. Please
state this as an authoring requirement.
Also, please state what an author may assume of processing defaults when
the minimum and maximum are not explicitly given.
--------------------------------
Response from the Working Group:
--------------------------------
We agree with your comment and will provide this information in the
specification. No platform accessibility API mapping is required to perform
error correction on bad data for these value properties. It leaves that
task to the assistive technology. We need to be consistent with WAI-ARIA.
----------------------------------------------------------------------
Comment 29: aria-owns is still complex
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0019.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-owns (property) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-owns>
Status: Alternate action taken
-------------
Your comment:
-------------
Could you please indicate whether the feedback at
http://lists.w3.org/Archives/Public/public-pfwg-comments/2008JanMar/0046.html
was unaddressed intentionally (why?) or accidentally?
--------------------------------
Response from the Working Group:
--------------------------------
- We have gone through extensive editing to make aria-owns clearer
- In Web 2.0 applications there is the potential to have an element owned
by more than one element. Also, the use of aria-owns is not limited to
grids. It may also be used on listboxes, trees, or other elements.
Consequently it is meant for re-use.
- aria-owns is provided through a separate API relationship property
separate from the parent/child hierarchy in the DOM so it does not conflict
with the DOM parent/child hierachy. This will be apparent in the ARIA user
agent implementation guide.
To address your suggestion about using aria-level, reusable Web 2.0
"owned" elements may reside at the end of a document so simply including an
aria-level attribute on an element does not associate it with the
appropriate container element. The element may only appear as a child of an
element when CSS is used to render it visibly as a child of the container.
Furthermore, for elements like options in a list box there is no notion of
a level.
Regarding your concern over producing cyclic structures we are modifying
the WAI-ARIA Implementation Guide to ensure that user agents protect
against recursion issues caused by cyclic structures similar to the way we
do for other relationships such as aria-controls and aria-describedby.
We were unable to address your question regarding "datagrid" as when we
reviewed the August 14 Whatwg draft and the August 12, 2009 W3C editors
draft of the HTML 5 specification a datagrid was listed as having special
parsing rules but no element was defined for it. In fact, it was the only
tag in the special parsing rule list that did not have a link to a
definition for that element. A challenge we have with referring to HTML 5
is that it is still in flux. datagrid would represent a new tag and at the
point that we integrate datagrid in HTML 5 we will need to modify the aria
implementation guide to address HTML 5 specifics.
----------------------------------------------------------------------
Comment 30: Indicate authoring expectations on grid SHOULD violations
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0020.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - grid (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#grid>
Status: Accepted proposal
-------------
Your comment:
-------------
ARIA says:
"Cells with role gridcell, SHOULD be contained in rows with role row,
which in turn SHOULD be contained in a grid."
Please indicate what well-defined UA behavior the author can expect when
violating the "SHOULD".
--------------------------------
Response from the Working Group:
--------------------------------
We have modified the the specification to provide have well-defined
behavior.
----------------------------------------------------------------------
Comment 31: Role inference in grids still unclear
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0021.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - grid (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#grid>
Status: Accepted proposal
-------------
Your comment:
-------------
Please indicate whether the comments in
http://lists.w3.org/Archives/Public/public-pfwg-comments/2008JanMar/0052.html
were left unaddressed intentionally or by accident.
The ARIA spec still doesn't say if the roles of rows, column headers and
focusable cells are inferred when an HTML table has role=grid or
role=treegrid.
The spec suggests that this might be intended but doesn't say so in clear
normative prose:
> There may also be cases where ARIA can augment an existing element in
the host language. For example, a grid and gridcell elements can reuse the
functionality of a table when overlaying it. ARIA roles, states, and
properties are best used when the markup language does not support all the
semantics required. When a role attribute is added to an element, the
semantics and behavior of the element are augmented or overridden by the
role behavior.
--------------------------------
Response from the Working Group:
--------------------------------
We have added text to address host language semantics.
----------------------------------------------------------------------
Comment 32: Inference from the DOM
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0022.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 <http://www.w3.org/TR/2009/WD-wai-aria-20090224/>
Status: Accepted proposal
-------------
Your comment:
-------------
ARIA says multiple times:
"Not required if inferred by the DOM."
However, it doesn't say how the relevant properties are inferred from the
DOM, so how is the author to know when an explicit property attribute is
required? Please state in the specification how the properties are inferred
from the DOM.
--------------------------------
Response from the Working Group:
--------------------------------
Thank you for your comment. In the most recent draft "Not required if
inferred by the DOM," only appears in relation to posinset and setsize. We
changed the text to "Not required if all elements in the set are present in
the DOM." and added an example.
----------------------------------------------------------------------
Comment 33: Informative 'must' still in ARIA
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0023.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 <http://www.w3.org/TR/2009/WD-wai-aria-20090224/>
Status: Accepted proposal
-------------
Your comment:
-------------
Please indicate if the feedback in
http://lists.w3.org/Archives/Public/public-pfwg-comments/2008JanMar/0063.html
was left unaddressed intentionally or by accident.
I suggest replacing the sentence
"Authors must associate elements in the document to an ARIA role and the
appropriate states and properties (aria-* attributes) during its
life-cycle."
with
"Authors may use the ARIA role attribute and the appropriate states and
properties (aria-* attributes) to communicate to assistive technology."
--------------------------------
Response from the Working Group:
--------------------------------
We agree that it is confusing to have normative looking statements in
informative text. We are developing rewording to avoid the confusion and
clarify the intent behind such statements, or converting them into
normative RFC 2119 statements where appropriate. We are also adding the
following clarification: "When the keywords shown above are used, but are
not formatted in bold and uppercase as shown, they do not convey formal
information in the RFC 2119 sense, and should be understood as merely
explanatory, i.e., informative. As much as possible such usages are avoided
in this specification."
----------------------------------------------------------------------
Comment 34: Please avoid calling schemas
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0024.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 9.1. Implementations <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#a_implementation>
Status: Accepted proposal
-------------
Your comment:
-------------
Section 9.1. is titled "Implementations". The section isn't about ARIA
implementations either in clients or in content. Instead, the section
contains informative schemas that do not completely capture the authoring
requirements and, thus, aren't quite implementations of expression of
authoring requirements either.
I suggest retitling the section accordingly as "Schemas" or "Schemata".
--------------------------------
Response from the Working Group:
--------------------------------
We agree the name of this section should be changed. We shall change the
title of section 9.1 to "Schemata".
----------------------------------------------------------------------
Comment 35: input type=search vs. role=search
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0025.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - search (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#search>
Status: Alternate action taken
-------------
Your comment:
-------------
As a follow-up to:
http://lists.w3.org/Archives/Public/public-pfwg-comments/2008JanMar/0069.html
<input type=search> has been adopted in HTML5 and has excellent graceful
degradation behavior. To avoid specifying overlapping features for the Web
platform, I suggest removing role=search from ARIA and saying that an
<input type=search> if it has no <form> or its <form> if it has one is "The
search tool of a web document."
--------------------------------
Response from the Working Group:
--------------------------------
The reason we have a search role is to define a regional landmark in the
page which may contain a text field, a set of checkboxes, and so on. For
example, you might have a checkbox which says case-sensitive. In short, the
search region of your page may constitute a number of widgets that control
the search that collectively form the search region. Consequently, search
is a role and a navigational landmark.
We shall make this more clear in our specification.
----------------------------------------------------------------------
Comment 36: aria-grabbed and aria-dropeffect relationship to HTML5 Drag&Drop unclear
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0026.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 5.5.3. Drag-and-Drop Attributes <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#dragdrop>
Status: Alternate action taken
-------------
Your comment:
-------------
Elaborating on
http://lists.w3.org/Archives/Public/public-pfwg-comments/2008JanMar/0076.html
HTML5 specifies drag and drop markup and APIs that were first implemented
in IE (well predating ARIA) and have since been implemented in WebKit and
Gecko.
http://www.whatwg.org/specs/web-apps/current-work/#dnd
Both ARIA and ARIA Best Practices are totally silent on the relationship
of the ARIA drag and drop attributes and HTML drag and drop.
http://www.w3.org/TR/2009/WD-wai-aria-20090224/#dragdrop
http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#dragdrop
Please indicate clearly what the relationship is. What information is
taken from the host language functionality and why it needs to be augmented
with the ARIA states, how authors should do it and how browsers should
expose all these to AT.
--------------------------------
Response from the Working Group:
--------------------------------
It is true that ARIA does not address the browser-specific implementations
of drag/drop. The reasons for this are numerous.
Widget libraries like Dojo do not make use of them. This may have in large
part to do with the fact that the implementations are inconsistent across
all browsers. Adding support for each proprietary implementation would
dramatically increase the code footprint which has had a heavier weighting,
in terms of objectives, than native drag/drop support. See inconsistencies:
http://developer.apple.com/documentation/appleapplications/conceptual/safarijsprogtopics/Tasks/DragAndDrop.html
Without ARIA support the person with disabilities has no information to
know the state of a drag operation or what is grabbable for drag and what
the drop effects are on the targets. Irregardless of implementation these
ARIA attributes can be used for all methods.
Also, all the proprietary methods will likely become obsolescent when HTML
5 implementations arrive. HTML 5 does support standard drag/drop but that
was first implemented in Firefox 3.5 which only recently came out.
The group does not have the resources required to author best practices
for proprietary drag&drop implementations. When a de facto standard arises
or the HTML 5 standard is finalized, the working group will reconsider
adding a best practice technique for a host language drag&drop example.
The HTML 5 native semantics for drag and drop form another model that
could be declaratively mapped directly to platform accessibility APIs. This
would render ARIA drag and drop redundant in the HTML 5 context, though it
still would need to be supported for backward compatability and for support
in languages that do not provide native semantics for drag and drop. We
will update the ARIA best practices guide for HTML 5 and its standardized
implementation of drag/drop when that feature is stable.
The PFWG continues to work with the HTML 5 WG to address issues of
duplicate functionality, including drag&drop.
----------------------------------------------------------------------
Comment 61: WAI-ARIA still lacks proper processing requirements
Date: 2009-04-14
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0040.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 5.6. Definitions of States and Properties (all aria-* attributes) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#state_prop_def>
Status: Accepted proposal
-------------
Your comment:
-------------
A year ago, I send feedback on the lack of processing requirements in
WAI-ARIA:
http://lists.w3.org/Archives/Public/public-pfwg-comments/2008JanMar/0078.html
Now it seems that WAI-ARIA informatively references WAI-ARIA User Agent
Implementation Guide. This means that ARIA still lacks proper normative
processing requirements on things that are independent of the
platform-dependent accessibility API in use.
Please normatively define processing requirements for ARIA.
P.S. I notice that even though I was invited to re-review ARIA this year
during this extended review period, many of my comments from a year ago
have gone unaddressed: neither fixed in the spec nor explicitly rejected;
despite the Process document saying:
"Starting with the First Public Working Draft until the start of a Last
Call review, a Working Group SHOULD formally address any substantive review
comment about a technical report and SHOULD do so in a timely manner."
It is rather demotivating to rereview a document only to find that the
previous comments have gone unaddressed. I'm reiterating my comments
specifically to invoke this "must" clause in the W3C Process:
"Starting with a Last Call review up to the transition to Proposed
Recommendation, a Working Group MUST formally address any substantive
review comment about a technical report and SHOULD do so in a timely
manner."
--------------------------------
Response from the Working Group:
--------------------------------
We will make the WAI-ARIA User Agent Implementation Guide normative, and
normatively reference it from the ARIA specification. This should provide
the normative processing model.
Regarding our failure to address your earlier comments, we have addressed
this concern at http://www.w3.org/WAI/PF/comments/faq and hopefully it has
already come to your attention. We apologize for this and certainly
understand your reaction. Once again, this was a failure of procedure, not
of intent, and we have improved our procedures to greatly reduce the
likelihood this will happen again.
----------------------------------------------------------------------
Comment 62: role=presentation has the aria-expanded state
Date: 2009-04-14
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0041.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - presentation (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#presentation>
Status: Accepted proposal
-------------
Your comment:
-------------
Why does role=presentation have a state if nodes with role=presentation are
meant to be flattened out of the accessible tree? What node is the state
supposed to exposed on if the node itself is not exposed?
See also:
http://lists.w3.org/Archives/Public/public-pfwg-comments/2008JanMar/0090.html
--------------------------------
Response from the Working Group:
--------------------------------
The presentation role inherits aria-expanded from its parent as a
structural element for which all structural elements should be expandable.
That said, we can see where having it here leads to confusion. We will move
the aria-expanded property from the structural role in the taxonomy to:
* document
* section
* sectionhead
* separator
This will allow the aria-expanded property to propagate to existing
structural roles in the taxonomy while eliminating it from the role
presentation.
----------------------------------------------------------------------
Comment 63: ARIA doesn't define number parsing
Date: 2009-04-14
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0042.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 5.3. Values for States and Properties <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#state_prop_values>
Status: Alternate action taken
-------------
Your comment:
-------------
Reiterating unaddressed comment:
http://lists.w3.org/Archives/Public/public-pfwg-comments/2008JanMar/0094.html
ARIA doesn't say how to parse numbers in attribute values
(particularly when the data is invalid).
I suggest adopting the HTML 5 microsyntaxes for numbers:
http://www.w3.org/TR/html5/#unsigned
http://www.w3.org/TR/html5/#real-numbers
--------------------------------
Response from the Working Group:
--------------------------------
We have made ARIA attribute types abstract without inherent formats. Host
languages would use corresponding types from that language for each ARIA
type. We are providing a recommended mapping from the abstract types in
ARIA to concrete types in known host languages. In this way, attribute
value syntax and processing rules come from the host language, not the ARIA
specification. Therefore, number representation and parsing rules for ARIA
in HTML documents would use the microsyntaxes you referenced.
Note that our recommended mappings for HTML are fairly straightforward,
except that ARIA boolean attributes are token attributes (accepting values
of "true" and "false", not HTML boolean attributes (where false can only be
declared by omitting the attribute). This is because of the way these
attributes have already been implemented and for greater portability
between host languages.
----------------------------------------------------------------------
Comment 64: Statement about events very vague
Date: 2009-04-14
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0043.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 1. Introduction <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#intro>
Status: Accepted proposal
-------------
Your comment:
-------------
An informative section in ARIA says: "Changing the role on an element from
its initial value will likely be treated by accessibility API events as the
removal of the old element and insertion of a new element with the new
role."
The above sentence implies that the WG hasn't formulated a proper
processing requirement for the case of a role change. Please formulate the
processing requirement normatively elsewhere in the document (or in a
separate document referenced normatively; the Implementation Guide is
currently referenced informatively) and then informatively recount the
behavior here.
--------------------------------
Response from the Working Group:
--------------------------------
We agree that processing of the role attribute does not belong in the
introduction and it has been removed. We have added normative processing
and added a paragraph to the start of paragraph 4 The Roles Model. This
change is not yet in place but we expect it to be in place in the next
public draft. This is our ACTION-468.
----------------------------------------------------------------------
Comment 65: Implementation of RDF?
Date: 2009-04-14
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0044.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 1. Introduction <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#intro>
Status: Accepted proposal
-------------
Your comment:
-------------
ARIA says:
"In addition to the prose documentation, the role taxonomy is provided in
Web Ontology Language (OWL) [OWL], which is an implementation of Resource
Description Framework (RDF) [RDF]."
It seems to me that neither OWL nor the role taxonomy is an implementation
of RDF. Rather, they seem to be layered on top RDF and might be called
'applications' of RDF.
--------------------------------
Response from the Working Group:
--------------------------------
We have changed "which is an implementation of Resource Description
Framework (RDF)" to "which is expressed in Resource Description Framework
(RDF)".
----------------------------------------------------------------------
Comment 66: Ambiguous "should" in an informative section
Date: 2009-04-14
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0046.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 2.3. Managing Focus <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#managingfocus>
Status: Accepted proposal
-------------
Your comment:
-------------
ARIA uses the normative key word 'should' in an informative section as
follows:
"The element with focus should not be destroyed, hidden, or scrolled off
screen."
Please make sure that normative-looking statements aren't made in
informative sections and please clarify if the sentence is aimed at user
agents or authors (and what happens if the 'should' is violated).
--------------------------------
Response from the Working Group:
--------------------------------
We agree that it is confusing to have normative looking statements in
informative text. We are developing rewording to avoid the confusion and
clarify the intent behind such statements, or converting them into
normative RFC 2119 statements where appropriate. We are also adding the
following clarification: "When the keywords shown above are used, but are
not formatted in bold and uppercase as shown, they do not convey formal
information in the RFC 2119 sense, and should be understood as merely
explanatory, i.e., informative. As much as possible such usages are avoided
in this specification."
----------------------------------------------------------------------
Comment 67: Contradictory recommended steps and examples
Date: 2009-04-14
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0047.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 2.4. Building Accessible Applications with WAI-ARIA <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#buildingaccessibleapplications>
Status: Accepted proposal
-------------
Your comment:
-------------
ARIA first says:
> Set roles to make sure elements behave predictably and correctly
describe the behavior of each element within the application, unless
element behaviors are fully described by the native markup language.
My emphasis on the part after the comma.
In the next section, the following example is given:
> <ul role="list" aria-labelledby="header" aria-owns="external_listitem">
<li role="listitem">Carrot</li> <li role="listitem">Tomato</li> <li
role="listitem">Lettuce</li> </ul>
Surely the element 'ul' is natively a 'list' and the 'li' element is
natively a 'listitem'.
Please avoid examples that contradict the stated recommended steps.
--------------------------------
Response from the Working Group:
--------------------------------
The example is meant to show the use of aria-owns within a tree when some
of its branches are not DOM children. There is an error in the markup of
the role attributes for the <ul>, <li>, and <div> elements. It should be:
... <ul role="tree" aria-labelledby="header"
aria-owns="external_treeitem"> <li role="treeitem">Carrot</li> ...
We will update the example accordingly.
----------------------------------------------------------------------
Comment 68: Normativity of role taxonomy
Date: 2009-04-14
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0048.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4. The Roles Model <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#role_model>
Status: Accepted proposal
-------------
Your comment:
-------------
The section on role taxonomy is marked normative, but it is entirely
unclear what it means for the taxonomy to be normative--particularly when
parts of the taxonomy are only a conceptual aid and aren't even allowed to
appear in content.
Please clarify what is meant of make the taxonomy modeling informative.
--------------------------------
Response from the Working Group:
--------------------------------
To make this clearer we shall change:
<change>
This section defines the WAI-ARIA role taxonomy and describes the
characteristics and properties of all roles. A formal RDF/OWL
representation of all the information presented here is available in
Appendix 8.1: Implementation.
</change>
<to>
This section defines the WAI-ARIA role taxonomy and describes the
characteristics and properties of all roles. A formal RDF/OWL
representation of all the information presented here is available in
Appendix 8.1: Implementation.
The roles, their characteristics, the states and properties they support,
and whether they may be used in markup, shall be considered normative. The
RDF/OWL representation used to model the taxonomy shall be considered to be
informative. The RDF/OWL taxonomy may be used as a vehicle to extend
WAI-ARIA in the future or by tools manufacturers to validate states and
properties applicable to roles per this specification.
</to>
The RDF/OWL provided in this specification was used to create the taxonomy
but is not the only vehicle that could be used to do so. It is intended to
be informative.
----------------------------------------------------------------------
Comment 69: Changing the expected behavior of option
Date: 2009-04-14
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0049.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.1.1. Parent Roles <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#parentrole>
Status: Alternate action taken
-------------
Your comment:
-------------
> If we change the properties and expected behavior of an option then the
properties and behavior of checkbox will also change.
Who is 'we' and how what mechanism would be used to change the expected
behavior of an option?
--------------------------------
Response from the Working Group:
--------------------------------
We agree this wording is confusing and therefore have removed the example
paragraph.
----------------------------------------------------------------------
Comment 70: Empty containers not allowed
Date: 2009-04-14
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0050.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.2.5. Required Child Elements <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#mustContain>
Status: Alternate action taken
-------------
Your comment:
-------------
> Note: When multiple roles are specified as "Required Child Elements" for
a role, at least one instance of one required child element is required.
This specification does not require an instance of each of the listed child
roles. For example, a menu should have at least one instance of a menuitem,
menuitemcheckbox, or menuitemradio. The menu role does not require one
instance of each.
Why aren't empty containers allowed? Empty containers might arise from
natural application states, and putting placeholders in containers just
complicates things.
--------------------------------
Response from the Working Group:
--------------------------------
It is important that when a user is going to operate a container there must
be something in it to operate. A user, who is blind cannot operate an empty
container and it can be disorienting. Rich Internet Applications are in
fact dynamic and we understand that during their generation content will be
in flux. However, giving focus to containers like menus that are empty is a
problem that we ask developers to supply a required child. Consequently, we
believe your concern is already addressed in two ways in section 4.2.5:
1. This note:
Note: There may be times that required child elements are missing, for
example, while editing or while loading a data set.
2. The must is lower case. It is a direction to the author to try to
provide a required child element. To avoid additional confusion with the
RFC-2119 terms, we have changed the lowercase 'must contain' to 'will
contain'.
----------------------------------------------------------------------
Comment 71: Name computation is vague
Date: 2009-04-14
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0051.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.2.7.1. Name Computation <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#namecomputation>
Status: Accepted proposal
-------------
Your comment:
-------------
> An accessible name may be computed by a number of methods, listed here in
order of preference:
Why doesn't the spec define one 'must' level algorithm here?
--------------------------------
Response from the Working Group:
--------------------------------
The accessible name computation in this section now refers to the User
Agent Implementation Guide where a normative computation, including a
number of MUSTS, is defined.
----------------------------------------------------------------------
Comment 72: Landmarks are redundant with native HTML features
Date: 2009-04-14
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0052.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.4. Definition of Roles <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#roles>
Status: Alternate action taken
-------------
Your comment:
-------------
The following roles complementary, contentinfo, main, navigation, search
are redundant with native HTML features and a native element corresponding
to banner could easily be introduced.
Is there a good reason why e.g. <div role=contentinfo> is promoted instead
of the HTML-native <footer> element? Exposing either to AT should require
about the same amount of UA programming work.
For reference, the correspondence is as follows:
complementary: <aside>
contentinfo: <footer>
main: <article>
navigation: <nav>
search: the <form> element associated with <input type=search>
Followup from
<http://www.w3.org/mid/B4AE1F76-17A4-46B3-A8AB-CD8D89FF1217@iki.fi>
I should mention that my previous message is a reiteration of the points
in
http://lists.w3.org/Archives/Public/public-pfwg-comments/2008JanMar/0085.html
That is, both role='contentinfo' and <footer> are equally invalid in HTML
4, which makes the previous answer unsatisfactory.
--------------------------------
Response from the Working Group:
--------------------------------
You seem to be saying that if a browser implements a feature that the
author may only use that feature. While we agree that authors should use
native elements when possible, and will promote that, the reality is that
when authors wish to create a UI element they may deem the native element
insufficient to meet their needs and choose to use a custom UI componet
with similar behaviors but requires ARIA to provide the same accessibility
semantics to the assistive technology as the native UI element. The use of
the ARIA attributes have no impact on the UI rendering.
As for ARIA landmarks, these can be used and nested throughout the
document based on its structure. For example, there may be a new document
within a web page which also has main content.
We consider that the following landmark roles as specified do not have an
applicable corresponding element in HTML5:
contentinfo, banner, main, and search. These to not have the same
semantics as your equivalent elements. Footer makes the assumption that the
content information is only located at the end of the document. The article
element does not have to be the "main" content. ARIA landmarks are large
perceiveble regions which must be navigated to. Consequently, the search
role represents the container of all the search criteria to execute a
search. This has been made clearer in the latest specification.
For the other HTML5 elements that map to landmark roles, we would
recommend their use once they are supported by Assistive Technology. What
we would recommend is that the landmark roles be added to native elements
that are similar, rather than using neutral elements.
A clarification will be added to the ARIA specification to recommend the
use of native semantics over ARIA sematics where applicable.
----------------------------------------------------------------------
Comment 73: alerts and focus
Date: 2009-04-14
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0054.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - alert (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#alert>
Status: Accepted proposal
-------------
Your comment:
-------------
> Alerts do not require user input and therefore should not receive focus.
Earlier spec text says that focus is 'managed'. Is the above sentence
meant as a requirement for content (authors should not make scripts focus
stuff in an alert) or for user agents (make it impossible to move the focus
to alerts)?
Please define the intended meaning in detail.
--------------------------------
Response from the Working Group:
--------------------------------
Neither the user agent nor the application is expected to set focus on an
alert. As the specification indicates it should be treated as an assertive
live region. Consequently, an assistive technology is expected to monitor
it. Like any live region, we do not prohibit the author from setting focus
on it, but we do not require it for the assistive technology to process it.
For these reasons, earlier versions of the specification were inaccurate
and consequently it has been changed.
Since this was not clear we shall make this change:
<change>
Alerts do not require user input and therefore should not receive focus.
Since alerts do not receive focus, authors SHOULD NOT require users to
close an alert.
</change>
<to>
Alerts are assertive live regions and should be processed as such by
assistive technologies. Neither authors nor user agents are required to set
or manage focus to them in order for them to be processed. Since alerts are
not required to receive focus, content authors SHOULD NOT require users to
close an alert.
</to>
----------------------------------------------------------------------
Comment 74: Interaction of role=heading and the HTML5 outline algorithm is undefined
Date: 2009-04-14
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0056.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - heading (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#heading>
Status: Alternate action taken
-------------
Your comment:
-------------
Either role=heading should be ignored by HTML UAs (and be invalid in HTML)
or some spec should say, in detail, how role=heading interacts with the
HTML5 outline algorithm.
Note that making it possible to make any element outline
algorithm-sensitive may preclude useful optimizations if in the future CSS
defines a markup-language-dependent selector for outline depth.
I think it would be preferable to promote the use of HTML native <h1>
through <h6>, which predate ARIA and can do all the JS and CSS tricks that
<div role=heading> can, and remove role=heading.
--------------------------------
Response from the Working Group:
--------------------------------
ARIA is intended to be applicable to more languages than HTML, so it
provides semantics that are already available in some host languages. The
heading role is needed for this reason.
We are adding the concept of "implicit ARIA semantics" - host language
features that are substantially similar to an ARIA feature. When features
in the host language are available for a given type of object, authors
should use those features rather than repurpose other elements with ARIA.
This rule would certainly apply to HTML headings vs the ARIA heading role.
We are considering the creation of an HTML-specific ARIA implementation
guide. This would be a place to document HTML features with implicit ARIA
semantics, and would also be a place to document the relationship, if any,
between the ARIA heading role and the HTML outline algorithm. We cannot yet
commit to this as it is a new deliverable for which we are not currently
chartered, but there are other places this information could also be added.
As part of the work on HTML 5 we will work with PF HTML working group
members to define text to address how ARIA would effect the outline feature
for the HTML 5 specification.
----------------------------------------------------------------------
Comment 75: Please do not define attribute value syntaxes in terms of XSD datatypes
Date: 2009-04-14
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0057.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 5.2.4. Value <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#propcharacteristic_value>
Status: Alternate action taken
-------------
Your comment:
-------------
> Value restrictions for the state or property. These restrictions are
expressed in terms of XML Schema Datatypes [XSD]. The following XSD
Datatypes are used in this specification.
>
> • boolean: a true/false value, expressed in attribute values
as true or false.
I think defining boolean as "true" or "false" makes sense, but that's not
what defining it in terms of XSD means! XSD also allows " true ", "false
", "0", "1", " 0", etc.
Please remove the reference to XSD and define the format for the attribute
datatypes in detail either by putting the entire definition in ARIA or by
referencing HTML5 microsyntaxes normatively.
Please do not allow leading or trailing whitespace in booleans,
enumerations (aka. NMTOKEN), numbers and singular IDREF values. Please do
not import the arbitrary XSD restriction that IDs must be NCNames; HTML5,
for example, allows a broader range of ID values.
--------------------------------
Response from the Working Group:
--------------------------------
We have made ARIA attribute types abstract without inherent formats. Host
languages would use corresponding types from that language for each ARIA
type. In this way documents can use the syntax for boolean values, token
lists, etc. in a way that is appropriate for the language of the document
as a whole.
We are providing a recommended mapping from the abstract types in ARIA to
concrete types in known host languages. This includes a mapping for HTML 5
(we welcome your input if you believe we have made inappropriate mappings).
HTML 5 documents that use ARIA would use the HTML 5 syntax for boolean
attributes, lists of tokens, etc.
Note that our recommended mappings for HTML are fairly straightforward,
except that ARIA boolean attributes are token attributes (accepting values
of "true" and "false", not HTML boolean attributes (where false can only be
declared by omitting the attribute). This is because of the way these
attributes have already been implemented and for greater portability
between host languages.
We are also providing a mapping to XML Schema Datatypes. This is intended
to be a general purpose recommendation for XML-based languages that do not
define their own datatypes. However, this has been removed from the core
definition of ARIA datatypes.
----------------------------------------------------------------------
Comment 76: 'undefined' unclear
Date: 2009-04-14
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0058.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 5.2.4. Value <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#propcharacteristic_value>
Status: Answered question
-------------
Your comment:
-------------
> The value undefined, when allowed on a state or property, is an explicit
indication that the state or property is not set.
Does this mean that the string "undefined" is a conforming state/property
value?
If so, it seems weird to allow such syntactic sugar compared to requiring
the attribute be removed.
--------------------------------
Response from the Working Group:
--------------------------------
We were concerned that giving meaning to the presence or absence of an
attribute, without reference to its actual value, would be problematic. We
considered use cases where the attribute is omitted by the author but
appears in the DOM as the result of a validation or transformation stage.
Whether that is correct behavior is another question, but we were concerned
that it could happen. We also didn't want to require authors to remove
attributes from the DOM as in some cases it might be less expensive to
change the value than to remove it.
Therefore, we wanted to provide a value for attributes that would have the
same meaning as if the attribute were not provided. "undefined" is a legal
token value for many attributes, but is also the default value. Thus, if
the attribute is absent the value reverts to that default, and if the
attribute is inserted by some process without author intervention, it would
also be given that default value.
In practice, authors who prefer can remove the attribute to get the
behavior prescribed by the "undefined" value. However, authors can also
provide the attribute with the value explicitly set to "undefined" to get
the same effect. Rather than viewing this as syntactic sugar, we consider
this a way to reduce possible error conditions.
----------------------------------------------------------------------
Comment 77: Mutations events and fundamental design of ARIA
Date: 2009-04-14
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0059.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 7.3. Web Application Notification of DOM Changes <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#ua_domchanges>
Status: Alternate action taken
-------------
Your comment:
-------------
> When a web application maintains a local representation of accessibility
information through ARIA roles, states, and properties, the user agent MUST
provide a method to notify the web application when a change occurs to any
of the states or properties. For example, if any software other than the
web application (such as the user agent, assistive technology, or a
plug-in) were to change the aria-activedescendant attribute of a tablist,
the user agent SHOULD fire a DOM mutation event so that the web application
can be notified and display the appropriate tabpanel. Likewise, web
application authors SHOULD listen for DOM mutation events when possible and
update the web application appropriately.
>
This section seems entirely inappropriate. It seems that ARIA everywhere
else assumes that DOM changes are not 'managed' but instead the author
scripts all the DOM changes in response to user input. Having assistive
technology cause a DOM mutation doesn't fit into this model at all.
Please remove this section.
--------------------------------
Response from the Working Group:
--------------------------------
We see this feature as necessary to ensure the robustness of WAI-ARIA and
accessible web applications. However, since DOM mutation events have known
performance considerations, we are modifying the wording to remove specific
mentions to DOM mutation events. Satisfaction of this requirement may be
achieved with DOM mutation event support, or with other future standards
currently in discussion.
----------------------------------------------------------------------
Comment 194: aria-label & aria-labelledby mutually exclusive?
Date: 2009-04-20
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0073.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-label (property) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-label>
Status: Alternate action taken
-------------
Your comment:
-------------
What must UAs do when the author has set both aria-label and
aria-labelledby? If one or the other takes precedence, shouldn't it be an
authoring error to specify both on one element?
--------------------------------
Response from the Working Group:
--------------------------------
The purpose of aria-label and aria-labelledby is identical -- to provide a
flat string short label. The difference is how the label is acquired.
Aria-label provides the text directly as the value of the attribute. In
contrast, aria-labelledby provides a reference to the label text.
Consequently, the presence of both is redundant. Either can be used, and
the label is the same in both cases. The use of one or the other depends
on whether the author wants the label text as part of the document content
(aria-labelledby) or not (aria-label). The aria-label section in the spec
states this rule [1]. We will add the rule to the aria-labelledby section
[2].
We will also add a statement to both sections indicating that their
purpose is equivalent.
Note that accessibility APIs have but one property available, typically
called the "accessible name". There being only one place to put a label in
the accessibility API means that if both aria-label and aria-labelledby are
present, one will be ignored. The user agent implementation guide's text
equivalent computation [3] effectively ignores any aria-labelledby if
aria-label is present. FireFox implements the algorithm in this way.
[1]
http://www.w3.org/WAI/PF/aria/20091214/states_and_properties#aria-label
[2]
http://www.w3.org/WAI/PF/aria/20091214/states_and_properties#aria-labelledby
[3]
http://www.w3.org/WAI/PF/aria-implementation/20091214/#mapping_special_te
----------------------------------------------------------------------
Comment 195: aria-label vs. HTML title attribute
Date: 2009-04-20
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0074.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-label (property) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-label>
Status: Accepted proposal
-------------
Your comment:
-------------
Please indicate when an author is supposed to use aria-label as opposed to
the HTML title attribute.
--------------------------------
Response from the Working Group:
--------------------------------
We have added author guidance to this section to clarify when to use
aria-label.
----------------------------------------------------------------------
Comment 196: Please specify the meaning of controls, invalid and required on non-widgets
Date: 2009-04-20
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0075.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 <http://www.w3.org/TR/2009/WD-wai-aria-20090224/>
Status: Alternate action taken
-------------
Your comment:
-------------
I find it peculiar that the latest draft of ARIA hoisted aria-controls,
aria-invalid and aria-required into global states and properties.
Please define what it means for an element that doesn't represent an input
widget to have an aria-controls attribute.
Please define what it means for an element that doesn't represent a
user-editable input field to be invalid or required. (Why aren't these
limited to the input widget ARIA roles, HTML <input> and <textarea> and
elements that have been made editable using contenteditable?)
--------------------------------
Response from the Working Group:
--------------------------------
After review, there are situations where aria-invalid may be the result of
a combination of widget/value pairs whereas individual values may be valid
by themselves but the aggregation may not be in which case it may be
necessary to apply aria-invalid to containers. This is a capability
unavailable in host languages but it must conveyed to the user. ARIA
provides that capability.
aria-required is allowed so that authors may apply these properties to
native host language elements, such as HTML 4.01 form elements, without
applying an aria role. We have moved aria-required from global properties
to specific ARIA input and container elements that require selection and
added restrictions as to their application in host languages.
aria-controls does not just apply to individual widgets. aria-controls may
be applied to a whole region of a document. This affords the author the
luxury of not having to apply aria-controls to every widget in a group when
the group collectively controls the outcome of another part of the web
page.
Since WAI-ARIA is a cross-cutting technology, we do not restrict these
properties to any specific host language elements in our specification.
----------------------------------------------------------------------
Comment 197: dropeffect a state?
Date: 2009-04-20
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0076.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-dropeffect (state) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-dropeffect>
Status: Accepted proposal
-------------
Your comment:
-------------
Shouldn't dropeffect be a property rather than state?
--------------------------------
Response from the Working Group:
--------------------------------
Yes, dropeffect should be a property and we have made that change.
----------------------------------------------------------------------
Comment 198: Drop effects seem mutually exclusive
Date: 2009-04-21
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0077.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 5.5.3. Drag-and-Drop Attributes <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#dragdrop>
Status: Proposal not accepted
-------------
Your comment:
-------------
It seems to me that copy, move, reference and popup are mutually exclusive.
If more than one of the first three effects is available, the value that
makes sense is popup.
Unless, of course, the spec means that copy, move and reference indicate
what will be available in the popup, in which case the old spec without
explicit "popup" made more sense, since the popup could be inferred from a
multitoken value.
It seems to me that the only effect that makes sense together with another
(as currently defined) one is execute.
--------------------------------
Response from the Working Group:
--------------------------------
One of the challenges of accessibility is that at the end of the day
authors may be restricted by their UI design team. The drop target may
support two or more of copy, move, or reference but the UI designer may
refuse to support a popup menu. They may, instead, choose to define a
specific key and key modifier to trigger the appropriate drop operation
when the target has focus.
The ARIA Best Practices Guide directs the author to document these
specialized keyboard control assignments. By providing the properties to an
assistive technology, such as a screen reader, the AT could enumerate the
possible drop options through speech. If a popup is indicated the user
knows there is a popup that may be used to select the drop operation.
WAI-ARIA allows for both scenarios.
----------------------------------------------------------------------
Comment 199: "may" about form submission contradicts a "must" requirement
Date: 2009-04-21
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0078.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-invalid (state) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-invalid>
Status: Alternate action taken
-------------
Your comment:
-------------
> User agents may refuse to submit the form as long as there is an element
for which aria-invalid is true.
contradicts this later MUST:
> WAI-ARIA processing by the user agent MUST NOT interfere with the normal
operation of the built-in features of the host language.
Please strike "User agents may refuse to submit the form as long as there
is an element for which aria-invalid is true." and inform authors that the
way to set custom validity of a form widget in a way that interacts with
HTML form submission is the setCustomValidity() method:
http://www.whatwg.org/specs/web-apps/current-work/#dom-cva-setcustomvalidity
--------------------------------
Response from the Working Group:
--------------------------------
We have changed the statement "User agents may refuse to submit the form as
long as there is an element for which aria-invalid is true."
to:
Where possible, authors may choose to prevent form submission when
associated form elements have aria-invalid="true".
We cannot specify setCustomValidity in the ARIA Specification as it is
only an HTML 5 feature. Also, different host languages may have different
mechanisms for controlling form submission.
We have created an action to include the setCustomValidity technique in
the WAI-ARIA Best Practices Guide when HTML 5 techniques are included.
----------------------------------------------------------------------
Comment 200: Why aria-expanded on role=application?
Date: 2009-04-21
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0081.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - application (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#application>
Status: Alternate action taken
-------------
Your comment:
-------------
If role=application is meant to be used on <body> or <svg> (why <body>
instead of <html>?), why would it make sense to unexpand the entire
application?
--------------------------------
Response from the Working Group:
--------------------------------
It is not the case that the application role can only be used on the body
or svg elements. They can be used on arbitrary elements, and there could be
multiple applications per page, any one of which could be expanded or
collapsed.
To answer your question about the body tag, the body tag is representative
of rendered content, while the html tag contains unrendered content.
Also, since application constitutes a navigational landmark, it may
applied to area landmarks to mark expandable and collapsible regions that
are flexible for managing content density for those with cognitive
impairments.
----------------------------------------------------------------------
Comment 254: SHOULD vs. MUST and abstract roles
Date: 2009-05-20
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0086.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.2.1. Abstract Roles <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#isAbstract>
Status: Alternate action taken
-------------
Your comment:
-------------
> Note: Abstract roles are used for the ontology. Authors SHOULD NOT
> use abstract roles in content.
Please make that 'MUST NOT', since using abstract roles is
unambiguously an error if user agents don't support the abstract roles
as concrete.
--------------------------------
Response from the Working Group:
--------------------------------
{From comment 12}
The working has take a position to limit author error conditions. As such
we have decided that use of abstraction roles should be that the author
SHOULD NOT use them and that User Agents must treat them as unknown roles
and MUST NOT process them. We shall also address this in the User Agent
Implementations Guide.
----------------------------------------------------------------------
Comment 255: role=math feedback/questions
Date: 2009-05-20
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0086.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - math (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#math>
Status: Accepted proposal
-------------
Your comment:
-------------
> The math role is used to indicate sections that represent math. Such
> sections SHOULD use a formal mathematical language such as MathML to
> express mathematical concepts.
>
This requirement makes no sense. The intrinsic semantics of MathML
already clearly flag any MathML content as being math, so requiring
role=math also would be pointless and against the stated principles of
ARIA.
> However, since there exists significant amounts of legacy content
> that use images and ASCII art to represent mathematical expressions,
> the math role also allows assistive technology to deliver to the
> user the text equivalent provided for the image, which can be
> converted, for example, to Braille or text to speech. The text
> equivalent used in such situations SHOULD be valid MathML or TeX.
>
Wouldn't putting MathML in alt of an <img> result in a bad user
experience for users of old AT?
Is AT supposed to implement MathML and TeX support? Have AT vendors
indicated that they'd do this?
How should the AT decide if the content should be interpreted as
MathML or TeX? Please define the sniffing algorithm.
What TeX macros should be available implicitly? Please define this in
detail.
How do you plan on assessing whether there exists two interoperable
implementations of this feature? (Surely this feature will be dropped
before REC if two interoperable implementations don't exist?)
> In order to be perceivable, images SHOULD also be labeled by text
> that describes the math formula as it should be spoken, using the
> aria-describedby attribute. The text description should have no
> special markup used to control a speech device.
>
Isn't it an overkill to require both MathML/TeX as 'text equivalent'
and the reading of the math as words as a textual description?
On the other hand, if the reading of the math as words were put in the
'text equivalent', wouldn't it be unnecessary to also flag content as
role=math, since the reading of e.g. the alt of an image would give
the reading of the math?
--------------------------------
Response from the Working Group:
--------------------------------
We have the refined the suggestions for how to label and describe math. A
human readable text label can be provided or a MathML or TeX label
associated with aria-labelledby or aria-describedby. There is no need to
provide a way to differentiate MathML from TeX because they are completely
different syntaxes that AT can recognize. There are no competing formats
from which they need to be differentiated either. Regarding interoperable
implementations, we only need to demonstrate recognition of the ARIA
attributes, not processing of math itself, which is a separate issue.
----------------------------------------------------------------------
Comment 256: aria-required vs. aria-expanded as global states/properties
Date: 2009-05-21
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0088.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 5.4. Global States and Properties <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#global_states>
Status: Answered question
-------------
Your comment:
-------------
What's the logic behind aria-required being global but aria-expanded
not being global? It seems to me that aria-expanded would be closer to
globally applicable than aria-required, which only makes sense for
inputs (including contenteditable).
--------------------------------
Response from the Working Group:
--------------------------------
The aria-required property is no longer global.
----------------------------------------------------------------------
Comment 257: aria-checked requiredness inconsistent
Date: 2009-05-21
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0089.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-checked (state) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-checked>
Status: Answered question
-------------
Your comment:
-------------
aria-checked is required on checkbox and menuitemcheckbox but not on
option.
--------------------------------
Response from the Working Group:
--------------------------------
We think you are confusing selected with checked states. The selected state
of an option is as it is currently specified in HTML, and in accessibility
APIs. Therefore, it is not required that the option has an associated
checked state, but may do so. Refer to the information in the specification
relating to the aria-selected state
(http://www.w3.org/WAI/PF/aria/20091214/states_and_properties#aria-selected).
----------------------------------------------------------------------
Comment 258: role=separator allows aria-expanded
Date: 2009-05-22
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0090.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - separator (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#separator>
Status: Proposal not accepted
-------------
Your comment:
-------------
Considering that aria-expanded isn't categorically allowed on
everything, it seems weird to allow it on role=separator. If
role=separator is similar to HTML <hr>, it doesn't take any content
and, thus, being expandable doesn't make sense.
--------------------------------
Response from the Working Group:
--------------------------------
A separator role is also applied to a splitter in a split-pane where the
pane can be expanded (shown) or collapsed. The split-pane separator would
be navigable by the keyboard.
It is true that an hr separator would probably not have script attached to
expand or collapse (show or hide) the following section but they could. At
the end of the day it, of course, it is also a separator. Consequently HTML
5 should not prohibit the use of aria-expanded on an <hr> element.
In the instances where a split-pane separator uses aria-expanded, the web
application author SHOULD apply an aria-controls attribute matching the ID
of the panel it collapses. Using this technique allows AT to be notified of
the expand/collapse event on the element that has focus, even though the
collapsed content is in the element associated with aria-controls. By
design, assistive technology ignores state change events outside the
focused element so as not to interrupt the user unless otherwise specified
on or in a live region.
----------------------------------------------------------------------
Comment 259: tablist and tabpanel in wrong order
Date: 2009-05-22
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0091.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.4. Definition of Roles <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#roles>
Status: Accepted proposal
-------------
Your comment:
-------------
Please sort tablist and tabpanel alphabetically.
--------------------------------
Response from the Working Group:
--------------------------------
We have fixed the alphabetical sorting of roles, states, and properties.
----------------------------------------------------------------------
Comment 260: Meaning of aria-level on role=rowheader and role=columnheader
Date: 2009-05-22
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0092.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-level (property) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-level>
Status: Accepted proposal
-------------
Your comment:
-------------
Please clarify what it means for a row/columnheader to have a level.
(It seems that in treegrids role=row already has aria-level for giving
the level of the row.)
--------------------------------
Response from the Working Group:
--------------------------------
We agree. aria-level has been removed from gridcell, rowheader, and
columnheader.
----------------------------------------------------------------------
Comment 261: Parent element for role=option seems wrong
Date: 2009-05-22
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0093.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - option (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#option>
Status: Accepted proposal
-------------
Your comment:
-------------
The spec says the parent element for role=option is select, which is
an abstract role some subroles of which don't make sense for option.
To keep the parent-child relationships sensibly reciprocal,
role=option should allow only role=listbox as parent.
--------------------------------
Response from the Working Group:
--------------------------------
Yes, this is an error. We are changing the required parent element of
option to be listbox.
----------------------------------------------------------------------
Comment 262: Must have at least one child of type vs. can only have children of type
Date: 2009-05-22
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0094.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.2.5. Required Child Elements <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#mustContain>
Status: Alternate action taken
-------------
Your comment:
-------------
ARIA defines "Required Child Elements" as "When multiple roles are
specified as "Required Child Elements" for a role, at least one
instance of one required child element is required."
It seems that it would be more useful to both allow empty collections
and to disallow children of other types in these cases. Therefore, it
would be more useful to change "Required Child Elements" to "Only
Allowed Child Elements".
(Please make the definition normative. I.e. please take it out of a
"note".)
--------------------------------
Response from the Working Group:
--------------------------------
We have moved the requirements out of notes to clarify that they are part
of the normative definition of this section.
The second (now promoted) note does allow empty collections under limited
circumstances (i.e., loading not complete), hopefully the ones you were
hoping to meet. It would not be meaningful to allow that generally,
however, as processing of the element may be undefined if the set of
required descendant roles is empty.
We do not wish to add the restriction that the required child elements are
the only child elements permitted. There may be child elements that are
relevant, such as grouping or labeling elements. It seems better not to
disallow this.
----------------------------------------------------------------------
Comment 263: Grouping in lists
Date: 2009-05-22
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0095.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - list (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#list>
Status: Accepted proposal
-------------
Your comment:
-------------
The spec should probably required that role=group as child of
role=list not have other roles than role=listitem as children.
--------------------------------
Response from the Working Group:
--------------------------------
We agree. We have added text to the group (role) to address this.
----------------------------------------------------------------------
Comment 264: Required children of role=combobox
Date: 2009-05-22
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0096.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - combobox (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#combobox>
Status: Accepted proposal
-------------
Your comment:
-------------
A role=combobox does not require a role=textbox as a child but
requires one role=listbox as a child? Please clarify how role=combobox
is supposed to work--in particular how the text entry part gets
implied by the role itself (if that's the case as it seems).
--------------------------------
Response from the Working Group:
--------------------------------
This is an error in the specification stemming from the fact that a native
text input field would suffice without having a role of "textbox." This, we
agree lends to confusion.
We are changing the specification to require textbox as a Required Child
Element. The combobox is the container.
----------------------------------------------------------------------
Comment 265: role=article not classified as a landmark
Date: 2009-05-22
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0097.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - article (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#article>
Status: Proposal not accepted
-------------
Your comment:
-------------
role=article isn't classified as a landmark, although it seems to
belong into that category conceptually.
--------------------------------
Response from the Working Group:
--------------------------------
That is correct. According to the HTML 5 specification, which we tried to
model, an article is a form of document and you will see that article
reflects this fact in the taxonomy hierarchy.
WAI-ARIA landmarks are large percievable areas in a web page. The reason
that we chose not to included it was because it can be extensively nested
as referenced in this HTML 5 text for article:
"When article elements are nested, the inner article elements represent
articles that are in principle related to the contents of the outer
article. For instance, a Web log entry on a site that accepts
user-submitted comments could represent the comments as article elements
nested within the article element for the Web log entry."
Consequently, articles can be deeply nested to form discussion threads
which could quickly result in their not becoming large perceivable regions
to navigate to. Consequently we decided to not make an article a landmark
and this was agreed upon with Freedom Scientific during discussions.
An important note is that just because an assistive technology does not
treat an article as a landmark does not mean that it cannot navigated by
article. A common screen reader/office suite navigation feature is to allow
navigation by semantics like paragraph, heading level, and so on. Imagine
having every paragraph listed in the list of landmarks.
Received on Tuesday, 15 December 2009 00:34:05 UTC