Response to your comments on Accessible Rich Internet Applications (WAI-ARIA) 1.0

Dear Benjamin Hawkes-Lewis:

Thank you for your comments on the 15 December 2009 Working Draft of
Accessible Rich Internet Applications (WAI-ARIA) 1.0
(http://www.w3.org/TR/2009/WD-wai-aria-20091215/). 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 9 December 2010 to say whether you accept them or to discuss additional
concerns you have with our response. If we do not hear from you by that
date, we will mark your comment as "no response" and close it. If you need
more time to consider your acknowledgement, please let us know. 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=6;

* 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/20101202/.

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 332: Clarify whether presentational children contribute to text equivalents
Date: 2010-09-12
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010JulSep/0049.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 5.2.7. Accessible Name Calculation <http://www.w3.org/TR/2009/WD-wai-aria-20091215/#namecalculation>
Status: Accepted proposal

-------------
Your comment:
-------------
Please clarify whether presentational children contribute to text
equivalent calculation. In particular, does role="presentation" affect
"host language … mechanisms" for associating labels with elements?

For example, given this markup:

   <div role="button"><img role="presentation" alt="Edit"
src="pencil.png"></div>

Should the accessible name of the button be "Edit" or ""?

See also the discussion in this thread on public-html-a11y:

http://lists.w3.org/Archives/Public/public-html-a11y/2010Sep/0349.html

--------------------------------
Response from the Working Group:
--------------------------------
In the presentation role, a normative requirement already mentioned that
this would flag an author warning, "Authors SHOULD NOT provide meaningful
alternative text (for example, use alt="" in HTML4) when the presentation
role is applied to an image.

For clarification of user agent implementation requirements, we have
incorporated that rule into the text alternative computation. Rule 2A
bullet 3 now states: "If aria-labelledby and aria-label are both empty or
undefined, and if the element is not marked as presentational
(role="presentation"), check for the presence of an equivalent host
language attribute…"

We are coordinating with accessibility test tool manufacturers to ensure
that when authors apply a role of "presentation" to images having non-empty
alternative text a warning is generated to web authors.

----------------------------------------------------------------------


Comment 333: Clarify whether how CSS replaced content would be included/excluded in accessible text determination
Date: 2010-09-13
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010JulSep/0051.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 5.2.7. Accessible Name Calculation <http://www.w3.org/TR/2009/WD-wai-aria-20091215/#namecalculation>
Status: Answered question

-------------
Your comment:
-------------
ARIA's accessible text determination method includes CSS generated
content:

"because it is possible to specify textual content using the CSS :before
and :after pseudo-elements, it is necessary for user agents to combine such
content with the text referenced by the text nodes to produce a complete
text alternative."

Currently, web developers use hacks to replace text with CSS added
content, such as moving text off-screen and putting a background image in
its. While these hacks do have negative accessibility impacts, they do not
affect the accessible text calculations.

CSS3 Working Drafts proposes new features for replacing content with CSS:

   * http://www.w3.org/TR/css3-content/#inserting3

   * http://www.w3.org/TR/css3-ui/#element

Here's some discussions of how web developers might want to use these
features to replace their current hacks:

   * http://www.css3.info/image-replacement-in-css3/
   * http://my.opera.com/ODIN/blog/css-3-image-replacement
   * http://css-discuss.incutio.com/wiki/Image_Replacement
   * http://dev.opera.com/articles/view/css-generated-content-techniques/

These have some experimental implementations. Both Opera and WebKit will
replace content with images, and Opera will also replace content with
text.

So how does this affect accessible text determinations?

Currently, Opera exposes original text *and* new text when text is
replaced with text, but exposes nothing when images are replaced. Likewise
WebKit exposes nothing when text is replaced with an image.

It would be good for ARIA to take a stand on this.

Should new text added with such features be included in accessible text
determinations? I'm guessing, by the current spec text by analogy with
:before and :after, it should be?

But then should original text replaced with such features be included in
accessible text determinations?

If original text is not included in accessible text determinations, then
accessibility-aware developers will need to continue to use either "img"
(with its costs to performance and skin-ability) or their existing hacks
(with their costs to accessibility).

If original text and new text are both included which should go first when
the accessible text is concatenated?

--------------------------------
Response from the Working Group:
--------------------------------
The :before and :after CSS textual content rules are handled by requiring
the UA to include the 'before' and/or 'after' text when computing the text
alternative.  This reflects a general rule, namely, that the UA "knows"
what the relevant text is.

The new CSS content rules provide additional ways to alter how text
content is rendered. These include:
- image replaces text.
- text replaces image.
- (new) text replaces (old) text.

> It would be good for ARIA to take a stand on this.

We agree.
- when an image replaces text, then the UA should use the original text,
since that text is presumably the equivalent.
- when text replaces an image, then the UA should provide that text.
- when new text replaces old, then the UA should include the new text,
since that is what is rendered on screen.

Aside:  There is a potential problem with an image replacing text where
the original text is the meaningless "put image #1 here".  In this case, we
would recommend using more descriptive text.  Compare this situation with
the recommendation that an author not use something like "image #1" for
@alt text.

> Should new text added with such features be included in accessible text
> determinations? I'm guessing, by the current spec text by analogy with
:before
> and :after, it should be?

Yes, but the wording should be done with care.  These new CSS content
rules are part of a working draft, and are not standard.  The ARIA
specification ought to reference other specifications that are settled, or
nearly so.  In addition, future versions of CSS might include even more
content rules that ARIA cannot anticipate. It is ultimately up to a group
working on CSS to define the accessibility API mapping of that information
when applied to a host language.

With that mind, we propose to add a general statement about CSS content
rules to the text computation algorithm.

----------------------------------------------------------------------


Comment 334: Media types and CSS generated content in accessible text determination
Date: 2010-09-13
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2010JulSep/0052.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 5.2.7. Accessible Name Calculation <http://www.w3.org/TR/2009/WD-wai-aria-20091215/#namecalculation>
Status: Alternate action taken

-------------
Your comment:
-------------
ARIA's accessible text determination method includes CSS generated
content:

"because it is possible to specify textual content using the CSS :before
and :after pseudo-elements, it is necessary for user agents to combine such
content with the text referenced by the text nodes to produce a complete
text alternative."

When UAs are generated accessible text, should they only include CSS
generated content from the media type they are rendering (typically
"screen") and ignore CSS generated content for other modalities that might
be relevant to AT (such as the CSS 2.1 "speech" and "braille" types, or the
proposed "reader" media type). If so, it would be good to make that
explicit.

It might be a good idea to have UAs expose multiple sets of accessible
text, as calculated for different media types, /if/ this wouldn't impose an
unacceptable performance cost on UAs and accessibility platforms would
allow that. That way AT could takes its pick.

--------------------------------
Response from the Working Group:
--------------------------------
Alternative modalities beyond screen are not in scope of ARIA 1.0. We have
created an issue to address this topic in a future version of ARIA. This is
our issue 425 http://www.w3.org/WAI/PF/Group/track/issues/425.

Received on Thursday, 2 December 2010 22:27:14 UTC