- From: Janina Sajka <janina@rednote.net>
- Date: Tue, 15 Dec 2009 00:34:49 +0000 (GMT)
- To: Jim Jewitt <jimjjewett@gmail.com>
- CC: PFWG Public Comments <public-pfwg-comments@w3.org>
Dear Jim Jewitt:
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 297: aria-describedby vs longdesc
Date: 2009-09-15
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009JulSep/0011.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-describedby (property) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-describedby>
Status: Proposal not accepted
-------------
Your comment:
-------------
(NOTE: it is understood that aria-describedby cannot point off page
directly.)
Ouch. Is it too late to allow URLs in place of IDREFs? (IDREFs could
of course still be done as #fragments.)
Or, at the very least, could the link suggestion be explicitly added
-- that aria itself would say that if the target ID is a link, then
the description is in the target of the link, rather than its
contents?
(HTML5 could probably do this by itself if it needs to ... but this
seems like something that ought to be fixed at the source level -- in
this case, the aria spec.)
--------------------------------
Response from the Working Group:
--------------------------------
We have found that developers do not use longdesc due to the burden of
having to create an entirely separate page and because it does not help
cognitively impaired users. Rather, it is more efficient to provide prose
on the same page to that can be referenced, for example, by an image using
aria-describedby. Consequently, we do not want to replicate the use of
longdesc functionality by making it refer to a link.
We have raised an issue (#359) for the ARIA Implementation Guide to
discuss the ability for UA/AT to, at a user's request, navigate to any
structured content referenced by aria-describedby.
----------------------------------------------------------------------
Comment 298: aria and multiple roles
Date: 2009-09-23
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009JulSep/0017.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: Answered question
-------------
Your comment:
-------------
(Bcc to the feedback address for the ARIA spec, Cc to the related
discussion group)
(1)
The aria spec currently states
(http://www.w3.org/TR/wai-aria/#host_general_role) that role must be a
space-separated list. It does not bar two of these tokes both being
aria roles.
Therefore it is possible to have multiple aria roles on the same
element. Is this intentional?
(2)
The html spec currently states
(http://dev.w3.org/html5/spec/Overview.html#annotations-for-assistive-technology-products-aria)
that role may not be used in "conflict with the strong native
semantics".
(2a) If it is possible for an element to have multiple roles, how
is conflict possible?
(2b) Does an explicit author-assigned role augment or replace the
roles derived from native semantics? (And is the answer different for
strong vs weak native semantics.)
--------------------------------
Response from the Working Group:
--------------------------------
Multiple roles are allowed in order to provide for fallback functionality
with future versions of ARIA, as well as for non-ARIA uses of the role
attribute. The spec defines that the first token that is a recognized ARIA
role is used, and the remainder are ignored. Other tokens may come from a
later version of ARIA than the user agent supports, or they may be non-ARIA
roles. This is explained in the spec at
http://www.w3.org/WAI/PF/aria/20091214/host_languages#host_general_role.
Note that for HTML 5, the issue of supporting role values that do not come
from ARIA may be moot. It is for the HTML Working Group to decide whether
the role attribute is used just for ARIA or whether it has a broader use
case. Our interest is focused on making sure there is a complete
implementation of ARIA in HTML. The need for fallback functionality with
future versions of ARIA does mean it needs to be a tokenized attribute,
even though at this time there wouldn't be a reason for an author to
provide more than one value.
Other technologies are using a role attribute that allows non-ARIA roles,
so the ARIA spec has to accommodate that.
----------------------------------------------------------------------
Comment 299: (aria-*) role and other values
Date: 2009-09-23
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009JulSep/0018.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: Answered question
-------------
Your comment:
-------------
(Bcc to the aria feedback, in case they wish to make a determination
for host languages in general.)
Is it conforming to use a role not currently defined in aria?
For example, aria does not define role="icon", so using it for my own
purposes is not currently barred by the aria spec
(http://www.w3.org/TR/wai-aria/#host_general_role).
I could easily imagine role="icon" being created later -- at which
point my document would become non-conforming. (Well, unless my own
use was fortuitously equivalent.)
I would expect aria to coordinate with other w3c groups before adding
values, but I would not expect them to coordinate with private usage.
(Of course, an "aria-role" attribute would avoid this problem, by
using aria's own pseudo-namespace.)
--------------------------------
Response from the Working Group:
--------------------------------
>From an ARIA perspective, it is neither conforming nor non-conforming to
use a role not from ARIA. The spec does accommodate the possibility that
the role attribute may be used for purposes other than ARIA.
The PFWG does not support a change to an "aria-role" attribute.
Implementations universally use the "role" attribute and it would introduce
a huge burden to change that. The HTML WG generally stated practice to
standardize around existing implementations when possible applies here.
----------------------------------------------------------------------
Comment 300: ARIA host language integration -- please clarify wording or intent
Date: 2009-09-29
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009JulSep/0019.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 1.2. Use Cases <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#usecases>
Status: Accepted proposal
-------------
Your comment:
-------------
Near the end of section 1 ( http://www.w3.org/TR/wai-aria/#usecases ), it
says:
ARIA is intended to be used as a supplement for native
language semantics, not a replacement. When the host
language provides a feature that is equivalent to the ARIA
feature, use the host language feature.
Please add the clarification "authors SHOULD"
ARIA is intended to be used as a supplement for native
language semantics, not a replacement. When the host
language provides a feature that is equivalent to the ARIA
feature, authors SHOULD use the host language feature.
Reason: In the HTML Working Group, a number of comments have been
made based on the understanding that ARIA annotations should be not be
available to scripts or CSS unless they conflict with the default
semantics of the element. There was even some concern about defining
the semantics in terms of aria roles/properties/states, because those
were somehow reserved for non-standard uses.
--------------------------------
Response from the Working Group:
--------------------------------
We have expanded our information about integration of host languages. In
that section we state "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". Although this is not in the use cases
section, it should address your request.
http://www.w3.org/WAI/PF/aria/20091214/host_languages#host_general_conflict
----------------------------------------------------------------------
Comment 301: ARIA integration -- role of host lang specifications
Date: 2009-09-29
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009JulSep/0020.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 2. Using WAI-ARIA <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#Using>
Status: Accepted proposal
-------------
Your comment:
-------------
After:
Authors must associate elements in the document to an ARIA
role and the appropriate states and properties (aria-* attributes)
during its life-cycle.
Please add something equivalent to "unless sufficient associations are
provided by the host language's native semantics." For example:
Authors must associate elements in the document to an ARIA
role and the appropriate states and properties (aria-* attributes)
during its life-cycle. (Note that many of these associations can
be provided automatically through the use of Host Language
Semantics.)
--------------------------------
Response from the Working Group:
--------------------------------
We have added material clarifying that features with implicit ARIA
semantics fulfill ARIA structural requirements. This is primarily in the
new section Implicit ARIA Semantics
http://www.w3.org/WAI/PF/aria/20091214/host_languages#implicit_semantics
but also in the introduction to Section 2 as you proposed and in other
relevant spots.
----------------------------------------------------------------------
Comment 302: ARIA integration -- (state and property) role of host lang specifications
Date: 2009-09-29
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009JulSep/0021.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.2.2. Required States and Properties <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#requiredState>
Status: Accepted proposal
-------------
Your comment:
-------------
States and properties specifically required for the role
and child roles. Content authors SHOULD provide
values for required states and properties.
Please clarify that this is only "unless these states and
properties can be be derived from native host language
semantics."
--------------------------------
Response from the Working Group:
--------------------------------
We have added material clarifying that features with implicit ARIA
semantics fulfill ARIA structural requirements. This is primarily in the
new section Implicit ARIA Semantics
http://www.w3.org/WAI/PF/aria/20091214/host_languages#implicit_semantics
but also in the introduction to Section 2 as you proposed and in other
relevant spots.
----------------------------------------------------------------------
Comment 303: aria -- how much can be inferred?
Date: 2009-09-29
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009JulSep/0022.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: Answered question
-------------
Your comment:
-------------
Any element that must be owned by the element with this role.
For example, an element with the role list must own an element
with the role listitem.
How explicit does this child role have to be?
(a) Is it enough that the native semantics imply the child role? (I
assume so.)
(b) Is it enough that the native semantics plus validity imply the
child role? (Not as sure.)
For example, in
<ul role=menu>
<li role="menuitem">Open file…</li>
is the <li> role optional, because host language semantics make it a
listitem, and the containing list is known to have the menu role?
--------------------------------
Response from the Working Group:
--------------------------------
Yes, it is enough if the native semantics are the same as the expected ARIA
role. We have added a section Implicit ARIA semantics
http://www.w3.org/WAI/PF/aria/20091214/host_languages#implicit_semantics to
the document to clarify this.
However, in your example, the role of "menuitem" on the <li> element would
be required. The implicit native semantic is not the correct one, and while
validity requirements suggest that hopefully the <li> element would be a
"menuitem", the user agent cannot infer this reliably. There could have
been an author error, or a different owned element fulfills the
requirement.
----------------------------------------------------------------------
Comment 304: aria role=presentation clarification
Date: 2009-09-29
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009JulSep/0023.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:
-------------
In the alphabetical listing of roles, it says:
presentation
An element whose role is presentational and does
not need to be mapped to the accessibility API.
I think it would be worth a note that the *children* should still be
mapped, unless ChildrenArePresenational is explicitly set true.
--------------------------------
Response from the Working Group:
--------------------------------
We agree that this sentence seems overly broad out of context. We have made
a modification to narrow the scope of the sentence.
Received on Tuesday, 15 December 2009 00:34:58 UTC