- From: Janina Sajka <janina@rednote.net>
- Date: Tue, 15 Dec 2009 00:33:36 +0000 (GMT)
- To: Ian Hickson <ian@hixie.ch>
- CC: PFWG Public Comments <public-pfwg-comments@w3.org>
Dear Ian Hickson:
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 5: role=
Date: 2009-03-25
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009JanMar/0028.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 6.1.1. Role Attribute <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#host_general_role>
Status: Proposal not accepted
-------------
Your comment:
-------------
ARIA has a lot of attributes, all but one of which are prefixed with the
string "aria-". Is there any chance we could also prefix role="" with
"aria-", as in aria-role=""? I understand that in some host languages,
the
attribute has other purposes as well, but it would be useful if, in the
host languages where that isn't the case, the attribute was prefixed. It
would keep all the attributes together in indexes and tables in
implementations, it would make it easier for authors to see their
accessibility API work, and it would highlight the link between the
various attributes. It would also allow ARIA to be used in vocabularies
that already have a role="" attribute (aria-* attributes are far less
likely to already exist than role="").
--------------------------------
Response from the Working Group:
--------------------------------
You subsequently requested to disregard your suggestion
(http://lists.w3.org/Archives/Public/public-pfwg-comments/2009JanMar/0031.html)
noting that there are already ARIA implementations using @role.
Consequently we will be keeping the role attribute as @role.
----------------------------------------------------------------------
Comment 267: WAI-ARIA allows meaningless combinations
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0027.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:
-------------
It seems that the WAI ARIA requires that host languages allow authors to
express a number of meaningless combinations, for instance:
* Specifying a role="" on an element whose purpose is another role, e.g.
WAI-ARIA appears to require host languages to allow the following:
<input type="checkbox" role="textbox">
* Specifying a state or property on an element in a way that contradicts
host language semantics, e.g. WAI-ARIA appears to require host
languages to allow the following:
<input type="checkbox" checked="checked" aria-checked="false">
I would like to request that host languages be able to state which roles
elements in the host language map to, and be able to forbid authors from
contradicting these roles. Similarly, I'd like to request that host
languages be able to define certain states and proprties that host
language attributes map to, with the corresponding ability to forbid
authors from contradicting these implicit states and properties.
Specifically, it is the following bullet point in section 6.1.1. Role
Attribute:
* The appearance of the name literal of any concrete ARIA role (see
section 7.3.2) as one of these substrings MUST NOT in and of itself
make the attribute value illegal in the host-language syntax
...to which I object.
--------------------------------
Response from the Working Group:
--------------------------------
We understand that there are situations in which ARIA can cause uncertainty
in processing. We particularly see that ARIA states and properties could
get out of sync with similar host language features (e.g., HTML "checked"
and ARIA "aria-checked").
To resolve this, we describe the concept of "implicit ARIA semantics" -
host language features that are substantially similar to an ARIA feature.
For ARIA states and properties, user agents are instructed to respect the
host language feature, not the ARIA one.
For roles, however, we have determined that it is best to continue to
require that the ARIA role always override the host language feature. There
may be situations in which this is not optimal, but in order to provide the
author with the ability to provide semantics regardless of issues with host
language semantics, we think this is crucial.
Host languages can define "strong native semantics" that should not be
overridden by ARIA. Authors are asked to respect this, and conformance
checkers can raise errors or warnings. Nevertheless, user agent behavior is
as described above.
We recognize this means that your example of <input type="checkbox"
role="textbox"> would be required to be treated as a textbox, because it is
a role. It would be an unusual authoring decision but one we felt was
important to allow. However, your example of <input type="checkbox"
checked="checked" aria-checked="false"> is one in which the ARIA attribute
would be ignored and the checkbox would be treated as checked.
Our changes do not remove the part to which you object, "The appearance of
the name literal of any concrete ARIA role (see
section 7.3.2) as one of these substrings MUST NOT in and of itself
make the attribute value illegal in the host-language syntax". One of the
use cases for ARIA is to retrofit existing semantically incorrect Web
content in order to improve its accessibility. In this use case, authors
may need to override existing native semantics in ways that might seem odd.
Because of that, we believe that all ARIA roles need to be permitted as far
as basic validity is concerned, and the user agent needs to process the
role. However, conformance checkers may raise errors or warnings when ARIA
roles conflict with strong native semantics, so hopefully authors will be
encouraged away from problematic uses.
----------------------------------------------------------------------
Comment 268: Use of SHOULD
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0028.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:
-------------
In a number of places in the WAI-ARIA draft, requirements use the level
SHOULD but it isn't clear why they are not MUST. In particular:
* Why is the use of abstract roles disallowed only as a SHOULD NOT? When
would it be ok to use them? (This requirement is present twice, once in
4.2.1. Abstract Roles and once in 4.3.1. Base Types. It is also given
explicitly for each abstract role, e.g. in the section named "composite
(abstract role)".)
* Why are authors only required to specify required attributes as a
SHOULD? When would it be ok to omit required attributes?
* Why is the requirement that the parent element be present only a
SHOULD? When is it ok to nest elements in ways that conflict with the
definitions in the spec?
--------------------------------
Response from the Working Group:
--------------------------------
We had previously decided not to have normative authoring requirements, but
have reversed this decision. Therefore, we are changing author "SHOULD"
statements to "MUST" statements in many cases, including the ones you
referenced.
----------------------------------------------------------------------
Comment 269: Conformance classes
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0030.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 7. Conformance <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#conformance>
Status: Accepted proposal
-------------
Your comment:
-------------
It would be useful to have a section that describes the conformance
classes that the WAI-ARIA spec is intended for. In general I recommend
following the guidelines described in the "QA Framework: Specification
Guidelines" document:
--------------------------------
Response from the Working Group:
--------------------------------
We have added a description of the various types of audience to whom the
specification is of interest, and indicated for each conformance
requirement to which audience it is targeted.
----------------------------------------------------------------------
Comment 270: must in 4.2.5
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0029.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: Accepted proposal
-------------
Your comment:
-------------
The "4.2.5. Required Child Elements" section uses the word "must"
(lowercase) in a way that appears to be a conformance requirement:
# Any element that must be owned by the element with this role.
It's not clear whether that is intended to be an RFC2119 MUST or just a
passing comment. If the latter, the section doesn't have any requirements.
Is the "Required Child Elements" line purely informative, with the
requirement given by the "Parent Element" line? If so, then it's not clear
how the relationship between a "list" and a "group" fits into the
requirements (since "group" doesn't require a "list" parent).
--------------------------------
Response from the Working Group:
--------------------------------
We have reworded this section to separate RFC2119 MUST aspects from
explanation of rationale.
It is not the case that required child elements must also appear within
given parent elements. In other words, required child elements and
(required) parent elements are not mirror requirements, but are separate
requirements applicable to different roles. We have added notes to each
section to clarify this.
We have adjusted the wording of the following two sections (which have
also been retitled):
Required Owned Elements
http://www.w3.org/WAI/PF/aria/20091214/roles#mustContain
Required Context Role http://www.w3.org/WAI/PF/aria/20091214/roles#scope
----------------------------------------------------------------------
Comment 271: Example contradicts list definition
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0029.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: Accepted proposal
-------------
Your comment:
-------------
The "For example" in the "4.2.5. Required Child Elements" section
contradicts the definition of "list", which allows "group" as well as
"listitem" to be a child.
--------------------------------
Response from the Working Group:
--------------------------------
We have changed the example to be one that would be less confusing.
----------------------------------------------------------------------
Comment 272: SHOULD in example
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0029.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.2.6. Parent Element <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#scope>
Status: Accepted proposal
-------------
Your comment:
-------------
The following example in "4.2.6. Parent Element" should probably not use
the RFC2119 term "SHOULD" since it's only an example requirement:
# For example an element with role listitem SHOULD be contained inside (or
# owned by) an element with role list.
--------------------------------
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.
----------------------------------------------------------------------
Comment 273: Clarify parent/child relationships in taxonomy vs. element hierarchy
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0029.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.2.6. Parent Element <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#scope>
Status: Accepted proposal
-------------
Your comment:
-------------
It would be good if the spec could be clearer about whether parent/child
relationships matter for the purpose of requirements on nesting. For
example, the spec says that "treeitem" is a child role of "listitem", but
it isn't clear if that means that you can put a "treeitem" in a "listbox"
It's clearly intended that a "row" can contain any kind of "gridcell"
including a "columnheader", so one might think the same applies for
"treeitem" and "listbox". However, "treeitem" itself says the parent
element must be a "tree".
--------------------------------
Response from the Working Group:
--------------------------------
We have clarified that subclass roles (such as your example of treeitem
subclassing a listitem) do not fulfill the requirements of child elements.
Therefore, treeitem would not fulfill the requirement of a listbox to have
listitem children. In order to address your example of the row role, we are
explicitly adding the rowheader and columnheader as options in the list of
required child elements. This was the only case in which this issue seemed
to apply.
----------------------------------------------------------------------
Comment 274: Unclear in focus navigation
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0029.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 6.1.3. Focus Navigation <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#host_general_focus>
Status: Accepted proposal
-------------
Your comment:
-------------
The bullet point in "6.1.3. Focus Navigation" is unclear. I have no idea
what it is trying to say.
--------------------------------
Response from the Working Group:
--------------------------------
We have clarified the wording to reflect that user agents must provide
programmatic access to focusable elements. We are moving that statement to
the WAI-ARIA User Agent Implementation Guide.
----------------------------------------------------------------------
Comment 275: Editorial work remaining
Date: 2009-04-02
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0029.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 9.1.1. Roles Implementation <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#a_impl_roles>
Status: Alternate action taken
-------------
Your comment:
-------------
The yellow box in "9.1.1. Roles Implementation" says that there is still
editorial work to be done.
--------------------------------
Response from the Working Group:
--------------------------------
We will remove the note, as it does not seem necessary to integrate the
references into the body of the spec as the note suggests.
----------------------------------------------------------------------
Comment 280: Slight confusion regarding listbox
Date: 2009-08-21
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009JulSep/0003.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - listitem (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#listitem>
Status: Accepted proposal
-------------
Your comment:
-------------
"listitem" is defined as "A single item in a list, listbox, or
directory.", but it isn't allowed in a "listbox" (you have to use
"option" instead).
--------------------------------
Response from the Working Group:
--------------------------------
This is an error. The reference to listbox has been removed from listitem.
----------------------------------------------------------------------
Comment 281: Roles for HTML elements
Date: 2009-08-22
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009JulSep/0004.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 <http://www.w3.org/TR/2009/WD-wai-aria-20090224/>
Status: Answered question
-------------
Your comment:
-------------
What roles should I use for the following elements?
<input type=date>
<input type=time>
<input type=datetime>
<input type=datetime-local>
<input type=month>
<input type=week>
<input type=color>
<input type=file>
<meter>
<time>
<keygen>
<dl>/<dt>/<dd>
<abbr>
<ruby>/<rt>/<rp>
<ins>/<del>
<figure>/<legend>
<iframe>/<embed>/<object>
<video>
<audio>
<caption>
<thead>/<tbody>/<tfoot>
<fieldset>/<legend>
<details>/<legend>
--------------------------------
Response from the Working Group:
--------------------------------
For a number of the elements you listed, there is no 1:1 correspondence
with WAI-ARIA roles. But more importantly, at the browser level, they
should be mapped directly to the OS-level accessibility APIs. WAI-ARIA
should only be in scope for these objects if an author decides to override
the browser default.
Steve Faulkner has provided additional advice in the following messages:
http://lists.w3.org/Archives/Public/public-html/2009Sep/0050.html
http://lists.w3.org/Archives/Public/public-html/2009Sep/0052.html
http://lists.w3.org/Archives/Public/public-html/2009Sep/0053.html
http://lists.w3.org/Archives/Public/public-html/2009Sep/0056.html
We are adding information about this to the WAI-ARIA User Agent
Implementation Guide. This is also a topic for the HTML Accessibility Task
Force.
----------------------------------------------------------------------
Comment 282: Roles not in ARIA
Date: 2009-08-22
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009JulSep/0004.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 <http://www.w3.org/TR/2009/WD-wai-aria-20090224/>
Status: Answered question
-------------
Your comment:
-------------
I'm assuming most elements, e.g. <p>, <em>, etc, should have no default
role, and should instead rely on styling. Is that right?
--------------------------------
Response from the Working Group:
--------------------------------
That is correct. ARIA does not specifically provide a role for these
elements. However, a user agent and accessibility API may choose to expose
a paragraph role if desired. We will consider additional roles in ARIA 2.0.
----------------------------------------------------------------------
Comment 283: display:none
Date: 2009-08-22
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009JulSep/0004.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-hidden (state) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-hidden>
Status: Answered question
-------------
Your comment:
-------------
I'm assuming elements that are display:none need no role as they are not
in the rendering. Is that right? If so, is "aria-hidden" redundant with
CSS? How should I integrate HTML's "hidden" attribute (which causes
display:none to be implied) with "aria-hidden"?
--------------------------------
Response from the Working Group:
--------------------------------
While elements are hidden, roles are not processed on those elements. Once
an element is no longer hidden, normal processing to determine its role
will apply, either by native semantics or by the @role attribute.
aria-hidden is provided to allow an assistive technology that access a
document from the DOM to know that the element is hidden via CSS. Browsers
seldom provide an API to access CSS information and even if they did it
adds an additional expense in performance for ATs.
Since HTML 5's hidden attribute is an equivalent host language semantic it
MUST take precedence over aria-hidden on elements where it is applicable.
This will be conveyed to assistive technologies which operate on the native
DOM. If CSS display:none is implied when using the HTML hidden attribute,
user agents MUST remove applicable input elements from the accessibility
API like they would do for any content with display:none applied.
----------------------------------------------------------------------
Comment 284: aria-owns vs radiogroup
Date: 2009-08-22
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009JulSep/0004.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - radiogroup (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#radiogroup>
Status: Answered question
-------------
Your comment:
-------------
What should I do regarding aria-owns/radiogroup for <input type=radio>?
--------------------------------
Response from the Working Group:
--------------------------------
ARIA provides a radiogroup role pertains to the labelled container for all
the associated radio buttons that would appear in a web page as users need
to visual groupings of radio elements. This is different than the HTML 5
radiogroup attribute which is an indicator of what radiogroup will have all
its other radio buttons turned off when a radio command is activated.
aria-owns has no control over that functionality.
If a radio command is located in the DOM outside the visible radiogroup
container the container simply refers to it with the aria-owns property. If
the group consisted of HTML 5 controls the author would also need to supply
the HTML 5 radiogroup attribute and provide it the collection identifier as
supplied in the specification.
As a best practice, for radio buttons that are grouped together in a
toolbar or elsewhere in the document, that they be visibly grouped together
in a container whose role is radiogroup and who ideally has a visible label
associated with it such as through aria-labelledby.
There may also be instances where the author does not use the HTML 5
standard radio commands and writes their own versions using other HTML
elements. This is a common Web 2.0 rich internet application practices. In
these instances the visible container having the role of radiogroup should
be applied and javascript employed to manage the selection of the radio
buttons.
----------------------------------------------------------------------
Comment 285: Spanning <th>
Date: 2009-08-22
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009JulSep/0004.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - rowheader (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#rowheader>
Status: Answered question
-------------
Your comment:
-------------
How should I expose <th> elements that have scope=rowgroup or
scope=colgroup?
--------------------------------
Response from the Working Group:
--------------------------------
WAI-ARIA is not meant as a complete replacement for HTML tables and does
not currently provide scope information for row and column headers. From a
WAI-ARIA perspective, there are no specific requirements and standard HTML
processing of these properties would apply.
We have created an issue to consider adding this feature to WAI-ARIA 2.0.
----------------------------------------------------------------------
Comment 288: No value for valuenow
Date: 2009-08-22
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009JulSep/0004.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - spinbutton (role) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#spinbutton>
Status: Alternate action taken
-------------
Your comment:
-------------
For an <input type=number>, which I presume should have role=spinbutton, I
have a situation in which the value (for aria-valuenow) might not be
known. However, it appears there is a conflict between the rules for
role=spinbutton (which require an aria-valuenow) and the rules for
aria-valuenow (which say it should be omitted in this case). What value
should I give the aria-valuenow property in this case?
--------------------------------
Response from the Working Group:
--------------------------------
If you have an element with a provided host language state or property
having semantics equivalent to that of WAI-ARIA the host language semantics
take precedence. If no value is present, the input should be identified as
invalid through the accessibility API. This is equivalent to an implied
aria-invalid="true". The user agent MUST then mark the current, max, and
min value as invalid by using a value of NULL of NaN if available, or 0 if
no value is supplied. This can also be done using aria-invalid as in fact
it is invalid.
If a value is supplied and either min or max values are supplied the user
agent MUST specify a maximum or minimum value for a floating point number
through the platform accessibility APIs.
We have created an issue to add to a HTML 5 implementation guide to apply
these rules when mapping native semantics to the platform accessibility
API. This is our ISSUE-389.
----------------------------------------------------------------------
Comment 289: autocomplete integration
Date: 2009-08-22
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009JulSep/0004.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-autocomplete (property) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-autocomplete>
Status: Accepted proposal
-------------
Your comment:
-------------
How should I integrate "aria-autocomplete" with the various autocompletion
mechanisms in HTML5, specifically list="" on <input>, autocomplete="" on
<form> and various controls, and UA-specific behaviour on all editable
controls?
--------------------------------
Response from the Working Group:
--------------------------------
The aria-autocomplete attribute applies only to elements whose role is
textbox. So, it provides additional information to the assistive technology
as to how the autocomplete would work that HTML 5 does not. If we were to
follow the non-normative table of input elements that support autocomplete
it would appear that it would apply to HTML 5 elements that are capable of
supplying a text input value. This would include the following input types:
(text, search, telephone, URL, e-mail, password, datetime, date, month,
week, time, datetime-local, number, color, range).
The list attribute on an input element is a suggestion to the user agent
to use the list provided. It can in fact be ignored by the user agent.
Since the browser has the ability to ignore the HTML 5 autocomplete and
list content attributes, per the spec., we cannot force the browser to
enforce its autocomplete mechanism based on aria-autocomplete. Following
the same convention, we suggest that the browser treat aria-autocomplete as
an author request to what the browser uses to fill in the listed input
elements in HTML 5.
For custom controls not created from HTML 5 input elements which convey
the appropriately defined semantics without ARIA, and for which the browser
is not designed to perform the autocomplete, we recommend that the author
MUST provide the aria-autocomplete properties where the custom control's
functionality matches the autocomplete functionality defined by the
WAI-ARIA specification.
The HTML 5 specification indicates that autocomplete only takes an on/off
value. It also indicates that autocomplete applies to the form element and
the input element, yet a non-normative table is included that indicates
autocomplete applies to only certain input controls. Clarification of this
is needed in the HTML 5 spec.
----------------------------------------------------------------------
Comment 290: Table row sections in ARIA grid model
Date: 2009-08-22
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009JulSep/0004.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: Alternate action taken
-------------
Your comment:
-------------
Does the presence of <thead>, <tbody>, and <tfoot> between elements with
role=row and role=gridcell have an effect on the ARIA conformance of a
document, given that it means the element with role=gridcell is not a
child of the element with role=row? If so, how should I address this
issue?
--------------------------------
Response from the Working Group:
--------------------------------
We have added a role "rowgroup" that fulfills the function of thead, tbody,
and tfoot. While this is an optional part of the grid structure, it maps to
the way HTML tables are structured and allows similar processing. Note that
this role does not differentiate between types of rowgroups, we will
consider that for ARIA 2.0.
----------------------------------------------------------------------
Comment 291: Drag and drop API
Date: 2009-08-22
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009JulSep/0004.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-grabbed (state) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-grabbed>
Status: Accepted proposal
-------------
Your comment:
-------------
How should I integrate "aria-grabbed" with the drag and drop API?
--------------------------------
Response from the Working Group:
--------------------------------
aria-grabbed can be controlled by authors, by using standard DOM API calls,
but we suspect that the HTML 5 working group would want developers to make
use of the HTML 5 features of drag and drop. If users with disabilities are
going to make use of HTML 5's drag and drop support, its functionality must
also be available to keyboard users. Currently, drag/drop is bound to mouse
events. For drag and drop to occur using the keyboard the user needs to
start the drag with the keyboard on draggable objects having
aria-dropeffect set and then drop the results on the target. To be able to
use HTML 5 functions it must be possible to call a device independendent
version of dragstart on the source object; dragenter and dragleave on
elements receiving keyboard focus, and a drop or cancel on the drop target
when it has focus. Today these functions are bound to mouse events.
If this capability were there for both mouse and keyboard navigation:
When initiating a drag operation the referenced list of source nodes MUST
automatically have the corresponding elements' aria-grabbed attribute set
to true provided they have aria-grabbed="false" When aria-grabbed="false"
it is the equivalent to element.draggable="true." This must also occur when
a new element is added to the drag when executing the
dataTransfer.addelement() method.
It should be assumed that all DOM child elements of the referenced source
nodes are are included in the drag.
There MUST be a programmatic way to start and cancel drag operations since
we are depending on HTML 5 to provide drag/drop capability. Currently, drag
events are triggered via mouse event. We shall log this as an issue.
Include text: Upon reception of the dragend event, the author MUST ensure
that for all source elements, capable of participating in another drag
operation, their aria-grabbed property is set to "false". For all other
elements the aria-grabbed property MUST be removed or set to "none".
We will work with you on integrating the appropriate language. This is our
ACTION-561.
----------------------------------------------------------------------
Comment 292: Dropeffect in drag and drop API
Date: 2009-08-22
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009JulSep/0004.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: Alternate action taken
-------------
Your comment:
-------------
Should the drag and drop API's dropEffect attribute affect the
"aria-dropeffect" state? If so, how?
--------------------------------
Response from the Working Group:
--------------------------------
People with disabilities need to know what the possible drop targets are
and the drop functions they support shortly after an object has been
grabbed as it is not always easy to find drop targets when they are
available. Consequently, as soon as an object is dragged the script writer
should mark *all* the drop targets with the supported aria-dropeffect based
on the object grabbed. This way an assistive technology may allow the user
to navigate directly to the drop target and choose the drop effect they
want.
It would seem that aria content attributes for aria-dropeffect should be
reflected back into the DOM attribute for dropeffect and vice-versa. To
allow for this symmetry we have changed the name of the aria-dropeffect
value of "reference" to "link". However aria-dropeffect also supports a
popup which you may or may not want in the DOM event. We also recommend
that you include an "execute" value, we use for dropeffect, if dropping
something on the target causes an execution, such as a form submittal or a
page restructure to occur. It is essential that a person with a disability
be able to know whether a drop operation can cause something relatively
major to occur so that the user can make the choice as to whether they want
to proceed.
We shall raise the appropriate issues against the HTML 5 specification to
ensure reflection of the aria-dropeffect content attributes and the
dropeffect DOM attributes. This is our ACTION-561.
----------------------------------------------------------------------
Comment 293: HTML labels
Date: 2009-08-22
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009JulSep/0004.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: Answered question
-------------
Your comment:
-------------
Should I expose the multitude of labels in HTML (title="" everywhere,
<option label="">, etc) using "aria-label"?
--------------------------------
Response from the Working Group:
--------------------------------
Where ever possible HTML attributes and elements should be mapped in the
browser directly to platform accessibility APIs. aria-label is used to
provide an accessible name on an element in the platform accessibility API.
The label attribute is a declarative representation of label in the host
language and MUST take precedence over aria-label which would do the same
thing. In the absence of either aria-label, or label, the title attribute
would be used to provide the accessible name in the platform accessibility
API if either the label or aria-label attribute are not provided in the
markup.
----------------------------------------------------------------------
Comment 294: Labelledby target non-existent IDs
Date: 2009-08-22
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009JulSep/0004.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-labelledby (property) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-labelledby>
Status: Answered question
-------------
Your comment:
-------------
How should I make "aria-labelledby" refer to elements that have no IDs, as
in the following case?:
<label>Name: <input name=fn></label>
It seems that in this case I need to imply an "aria-labelledby" on the
<input> to point to the <label> but I don't see how to do it since there's
no ID on the <label>.
--------------------------------
Response from the Working Group:
--------------------------------
If we read the HTML 5 specification right the first descendant "Name:" is
the label for the input field. The user agent can simply perform the
accessibility API mapping by creating a labelledby relationship from the
input field to the name: text. I would think that you would have two
descendants - one for the Name: text and one for the input field.
aria-labelledy is necessary when the label has no semantic relationship to
the element it is labeling. In this situation the HTML 5 specification
specified the relationship in a declarative fashion. Hence, the author does
not need to use aria-labelledby for this scenario. The user agent can do
the heavy lifting.
----------------------------------------------------------------------
Comment 295: Placeholder attribute
Date: 2009-08-22
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009JulSep/0004.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 <http://www.w3.org/TR/2009/WD-wai-aria-20090224/>
Status: Answered question
-------------
Your comment:
-------------
How should I expose the placeholder="" attribute on <input>? Should I map
it to "aria-label"? What if there is a placeholder and an explicit
<label>; should I give both?
--------------------------------
Response from the Working Group:
--------------------------------
Actually no. The placeholder attribute is equivalent to help text, similar
to the XForms hint text which is the accessible description. A similar
situation would occur if you had an aria-describedby property that was
hidden. The user agent MUST map the placeholder text to the accessible
description. The label would be derived from the label text preceding the
input field and would manifest itself in the accessibility API as the
accessible name.
We expect to create an HTML 5 implementation guide and will ensure this
mapping is documented for each platform accessibility API. This is our
ISSUE-387.
Received on Tuesday, 15 December 2009 00:33:46 UTC