- From: Janina Sajka <janina@rednote.net>
- Date: Tue, 15 Dec 2009 00:34:31 +0000 (GMT)
- To: Kelly Ford <kford@windows.microsoft.com>
- CC: PFWG Public Comments <public-pfwg-comments@w3.org>
Dear Kelly Ford:
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 166: Concerns with presentation and impact on text alternatives
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0069.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: Alternate action taken
-------------
Your comment:
-------------
We believe that role=presentation is problematic, beginning with the word
"presentation", continuing on to possible misinterpretation of what should
be presentation, and possible mis-use of role=presentation by authors who
want to avoid extra effort, thereby hiding real information from AT who
respect that role.
We understand where "presentation" comes from historically, and do have
some mixed feeling about raising this as an issue, but we believe the role
for images (and other elements) that are presentation, more correctly boils
down to role=informational and role=noninformational (or decorative)
elements.
We think the examples flagged are a good discussion point for abuses, well
intentioned or otherwise, of role=presentation. This needs more
clarification/examples as developers are going to get confused from
the outset and we'll be stuck with bad implementations from the outset.
In case you've not seen it there was a discussion on the Free
ARIA list just a few days ago on screen reader support for
role=presentation and what it means
http://groups.google.com/group/free-aria/browse_thread/thread/73a6b0d33c140273.
So role=presentation is descriptive of presentational elements (such as
tables, spacers etc) but not the content in these. As such links or
text in a table are parsed but not TH, TD etc or alt text (*if* I
have
followed the conversation correctly). For me the choice of the
word
"presentation" is confusing because we are all working from the notion
that either an element is completely accessible or completely not.
A. Assume I am a user of mobile device browser in Ghana. The
connection is slow and I turn off images in the mobile browser to
improve rendering speed. Note: a mobile device browser being thin
MAY not support aria. Also, why bother with ARIA if there is no AT on the
platform?
We do understand that many cell phones do now have AT and we hope that
this will only
improve and get more widespread. Some in UAAG can see a use case
for
people who are not disabled to use AT on cell phones as the context is
so
disabling in itself. Is this just an authoring issue that the UA will
ignore/repair that which it does not understand.
With AT on the platform, if ARIA was supported on mobile, wouldn't one
benefit be to help all users with tabbing within widgets and so on?
What should be displayed if the valid code below is presented on a mobile
browser that doesn't support ARIA and has image rendering off?
<p>
You can <span id="a1">update</span> your personal data or
<span id="a2">delete</span> it using the following buttons.
</p>
<div class="coolbutton" role="button">
<a href="blah-update-info.php"><img src="update.png" alt=""
labeled-by="a1"></a>
</div>
<div class="coolbutton" role="button">
<a href="blah-delete-info.php"><img src="delete.png" alt=""
labeled-by="a2"></a>
</div>
If our assumption is right, labeled-by without alt breaks things for
users on less capable devices (meaning potentially the large and
growing
percentage of the global population who browse the Web on less
sophisticated mobile phones).
Granted, the above example is *stretching* things to make a point,
and should be covered by Best Practices or Techniques. Our concern is
that
what may work well on constrained devices/bandwidths currently will
stop
working if developers decide to implement accessibility using ARIA.
Frequently if there's the potential to do incorrect coding , it will
happen. If developers do not create mobile versions and sniff for
UA/platform, what can be done? This might also be an item to bring to the
requested review of "Relationship between Mobile Web Best Practices
(MWBP) and Web Content
Accessibility Guidelines (WCAG)"
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Accessibility/drafts/ED-mwb
p-wcag- 20090218/
We'd personally like to see a solution whereby different versions do not
have to be written for mobile as this just fragments the web.
B. Role="presentation" tells the UA/AT that the element (and *some*
content) is presentational and not of interest. The UA is not expected to
expose "it" to the accessibility API. We find the text in the ARIA docs
overly vague.
For example:
"a table marked presentational results in the table, td, th, tr, etc being
removed, while text elements are left."
What happens to caption or summary if present and including text? Are they
left?
What about the content in the table that has no other markup other than
the structure provided by the table? Does the UA wrap all content in
<div> and add a <br /> between each cell and <p> for each row?
What about images in the table, which are not text, but contain
labeled-by?
This begins to seem like a lot of work on the part of the UA to
decide/parse what to include and what not to, especially if coding by
authors is haphazard (which we can assume it will be in some cases).
We are also unclear on what MAY or SHOULD (etc) be picked up by the
UA (http://www.w3.org/TR/wai-aria/#presentation) means.
Wouldn't this lead to inconsistent implementations?
We can envision code that passes validation but is a mess in terms of
what the UA has to interpret and expose to AT. What if a
misguided author decides, mistakenly that his data table, authored to
look beautiful, is presentational? What about a data table that is
contained within a layout table marked presentational? What are the rules
for nesting of presentation structure?
Has anyone estimated the processing that will have to take place on
the part of both the UA and AT to properly walk the DOM, apply
rules, and extract the information for the accessibility API?
Being a good UA/AT, what would I do with the following:
<p>There is nothing to see here. Move along.</p>
<div role="presentation">
I lied, there is something here and it is very interesting. <a
href="special.html">For your eyes only</a>
</div>
Do I assume that all text within the div marked role=presentation is
displayed... or is only the anchor element content displayed?
What happens if I then put role="presentation" on the anchor element?
Of course, the example is not likely, but you never know how or why it
might get used for devious or well-intentioned reasons.
Where are the specified rules that help a developer understand the
precise way to implement this in a UA for all element types, nested or
not?
C. We know this is an extreme example, but:
<img src="orgchart.png" labelledby="o1">
<div labeledby="o2" id="o1" role="presentation">placeholder</div>
<div id="o2">Organization chart for TPG</div>
We assume the above is valid code. What is the result?
--------------------------------
Response from the Working Group:
--------------------------------
There are a number of questions asked in this note and we will try to
address each one.
The first has to do with the presentation role.
The use of role="presentation" is not meant to be informational or
non-informational. It means the corresponding element is meant to effect
the presentation of the user interface and in most cases the layout. Its
use effects what is exposed to the assistive technology by removing these
presentational elements from the accessibility API tree. Steve Faulkner
addressed this point on the free-aria reference that you sited.
Consequently, Role="presentation" in no way impacts the visual browser
rendering and these elements still appear in the DOM.
If the content does in fact mark content with role="presentation" and it
is not then it is a violation of WCAG 2's Robust checkpoint. So, using
role="presentation" incorrectly is as much of an accessibility violation as
leaving out alt text on an image. Furthermore, ATs have to do a
considerable amount of historisis to guess at whether something is
presentational or not. This results in errors and performance issues.
To further ensure that a role of presentation is not applied improperly we
have made exceptions in the implementation guide to not honor it when
situations arise such as its application to a focusable object. We have
also improved the definition of the presentation role in the specification
to improve clarity. Today there is extensive use of the presentation role
in the industry.
Consequently, we shall continue to use the name presentation.
To address your question regarding the need for ARIA when there is no AT
on the platform such as a mobile browser:
Not everyone will need to use ARIA. In fact the YUI team has made their
ARIA support pluggable. If your application knows you are shipping content
to a mobile device with no accessibility support don't add it and in fact
don't bother including HTML labelfor's. If the platform is inaccessible
then by all means don't do any accessibility work. This is issue is not
limited to ARIA. It is also safe to say that there is a lot of content that
is omitted when being sent to a mobile device to limit the amount of
information available in line with the available screen real estate.
Finally, if ARIA is added and their is no AT support then the browser
simply ignores them unless they are used to trigger CSS attribute selectors
which is no different than any properties in HTML whether they are included
in the language or not.
To address you comment "wouldn't one benefit be to help all users with
tabbing within widgets and so on?"
Yes, if the device supported a tab key equivalent.
>What should be displayed if the valid code below is presented on a mobile
browser that doesn't support ARIA and has image rendering off?
><p>
>You can <span id="a1">update</span> your personal data or
><span id="a2">delete</span> it using the following buttons.
></p>
><div class="coolbutton" role="button">
><a href="blah-update-info.php"><img src="update.png" alt=""
>labeled-by="a1"></a>
></div>
><div class="coolbutton" role="button">
><a href="blah-delete-info.php"><img src="delete.png" alt=""
>labeled-by="a2"></a>
></div>
>
>If our assumption is right, labeled-by without alt breaks things for
>users on less capable devices (meaning potentially the large and growing
>percentage of the global population who browse the Web on less
>sophisticated mobile phones).
>
>Granted, the above example is *stretching* things to make a point,
>and should be covered by Best Practices or Techniques. Our concern is
that
>what may work well on constrained devices/bandwidths currently will stop
>working if developers decide to implement accessibility using ARIA.
We agree that given that mobile devices have not transitioned to using
ARIA and that there may be instances, like this where if the author uses
ARIA vs traditional HTML content that some some features of mobile browsers
will not be as functional as they are today. That said, one could argue
that the new features of HTML 5, like the tabindex modification (originally
found in IE 5) to allow focus to elements without impacting the tab order
could also impact keyboard navigation on a mobile device. What happens in
these cases is that mobile authors do create different content to fit less
functional delivery contexts. Your point that the use of labelledby while
ommitting the alt text would impact the UI and that a more appropriate
solution like the following could be employed:
<div role="img" aria-labelledby="caption">
<img src="example.png" role="presentation" alt="">
<p id="caption">A visible text caption labeling the image.</p>
</div>
We will address the issue of alternative text and mobile devices in the
Best Practices Guide and include an example showing the problem and offer
this as an alternative solution. This way the content only need be written
once and share this with the MWBP.
>Frequently if there's the potential to do incorrect coding , it will
happen. If developers do not create mobile versions and sniff for
UA/platform, what can be done? This might also be an item to bring to the
>requested review of "Relationship between Mobile Web Best Practices (MWBP)
and Web Content
>Accessibility Guidelines (WCAG)"
>http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Accessibility/drafts/ED-mwbp-wcag-
20090218/
>
>We'd personally like to see a solution whereby different versions do not
have to be written for mobile as this just fragments the web.
>B. Role="presentation" tells the UA/AT that the element (and *some*
content) is presentational and not of interest. The UA is not expected to
expose "it" to the accessibility API. We find the text in the ARIA docs
>overly vague.
>For example:
>
>"a table marked presentational results in the table, td, th, tr, etc
being removed, while text elements are left."
>
>What happens to caption or summary if present and including text? Are
they left?
>
>What about the content in the table that has no other markup other than
the structure provided by the table? Does the UA wrap all content in <div>
and add a <br /> between each cell and <p> for each row?
>
>What about images in the table, which are not text, but contain
labeled-by?
>
>This begins to seem like a lot of work on the part of the UA to
decide/parse what to include and what not to, especially if coding by
authors is haphazard (which we can assume it will be in some cases).
The use of role="presentation" is meant to express the intent of the
author and not that it is not interesting. Detailed mappings to platform
accessibility API shall be addressed in the User Agent Implementation Guide
and we will ensure that the accessibility API mapping is clearly
articulated for each supported platform.
>We are also unclear on what MAY or SHOULD (etc) be picked up by the
>UA (http://www.w3.org/TR/wai-aria/#presentation) means. Wouldn't this
lead to inconsistent implementations?
We have firmed this up in the next draft and we have made the user agent
implementation guide response to the presentation role normative.
>We can envision code that passes validation but is a mess in terms of
>what the UA has to interpret and expose to AT. What if a misguided author
decides, mistakenly that his data table, authored to look beautiful, is
presentational? What about a data table that is contained within a >layout
table marked presentational? What are the rules for nesting of presentation
structure?
>
>Has anyone estimated the processing that will have to take place on
>the part of both the UA and AT to properly walk the DOM, apply rules, and
extract the information for the accessibility API?
>
>Being a good UA/AT, what would I do with the following:
>
><p>There is nothing to see here. Move along.</p>
><div role="presentation">
>I lied, there is something here and it is very interesting. <a
href="special.html">For your eyes only</a>
></div>
>
>Do I assume that all text within the div marked role=presentation is
displayed... or is only the anchor element content displayed?
It is all displayed unless one of the elements within the <div> is also
marked as presentational. Presentational div text would then move up a node
as the div disappears from the accessible object tree.
>What happens if I then put role="presentation" on the anchor element?
>
There would be no accessibility API mapping and an accessibility test tool
should flag this as a violation. Also, if the anchor is a link, it is
focusable. In this case, the UA ignores the presentation role. See the ARIA
user agent implementation guide section on the accessibility tree and
overrides of the presentation role:
http://www.w3.org/TR/2009/WD-wai-aria-implementation-20090224/#intro_treetypes.
>Of course, the example is not likely, but you never know how or why it
might get used for devious or well-intentioned reasons.
>
>Where are the specified rules that help a developer understand the
precise way to implement this in a UA for all element types, nested or
not?
>
>C. We know this is an extreme example, but:
>
><img src="orgchart.png" labelledby="o1">
><div labeledby="o2" id="o1" role="presentation">placeholder</div>
><div id="o2">Organization chart for TPG</div>
>
>We assume the above is valid code. What is the result?
It is an extreme example and it is unclear why anyone would do this as we
see no value in marking a div as presentatonal. The answer is it depends on
the accessibility API mapping. A UI Automation mapping would be different
from say IAccessible2 and ATK. That said, by removing the div with
role="presentation" placeholder would become a sibling of img. Both labels
would become invalid and not be mapped to an accessibility API. This should
be similar to ATK on Linux. We will make sure the User Agent Implementation
Guide addresses what happens when a <div> is marked as presentation and how
it impacts labelling.
----------------------------------------------------------------------
Comment 167: Separate keyboard access
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0069.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: Alternate action taken
-------------
Your comment:
-------------
Step 3 here is titled 3. Preserve semantic structure. The end of
this makes passing reference to keyboard access. Keyboard access
should be broken out as a separate step and the expectation
strengthened to say something about supporting keyboard navigation
expected for the role in use. Step 6 seems to do this so why then is
keyboard access in step 3? This does seem to dangle. The entire
last sentence "facilitate keyboard navigation." would be better in Step
6.
--------------------------------
Response from the Working Group:
--------------------------------
Our intent here was to ensure that the author provides document level
semantics to large perceivable regions. The benefits go beyond keyboard
navigation. We have reworded this text to be more in line with this intent
vs. solely focusing on keyboard navigation which is the intent of Step 6.
----------------------------------------------------------------------
Comment 168: First letter navigation in trees
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0069.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 2.5. Example: Building a Tree Widget <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#Exampletree>
Status: Accepted proposal
-------------
Your comment:
-------------
This talks about keyboard behavior for a tree but ignores first letter
navigation to tree elements. This is basic behavior for tree controls on
Windows and Mac. We are not 100% certain on linux but believe it is true
there also so should be supported by the author using ARIA and in this
example. We recognize this could be a lot of extra work on the part of the
author and raise this is something to be considered for enhanced
accessibility.
--------------------------------
Response from the Working Group:
--------------------------------
The ARIA specification is not meant to provide a full keyboard
implementations. This is intended for the WAI-ARIA Best Practices Guide. To
address your concern we made a reference in section 2.5 to the Design
Patterns section of the of the Best Practices Guide for detailed tree
widget keyboard implementation.
----------------------------------------------------------------------
Comment 169: clarify base concept
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0069.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 4.1.4. Base Concept <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#baseConcept>
Status: Accepted proposal
-------------
Your comment:
-------------
This sentence is confusing:
However, if the HTML checkbox is modified, the definition of a Checkbox
in this document will not be not affected, because there is no actual
inheritance of type.
--------------------------------
Response from the Working Group:
--------------------------------
As 4.1.4 indicates, Base Concept, is simply meant to provide informative
information about an object in the taxonomy - meaning, in this example,
that a checkbox is similar to the base concept of an HTML checkbox. By
informative this is documentation, in the form of RDF, and does not in any
way impact the object, how it is processed by an assistive technology or
what states and properties it supports.
we have clarified the example.
----------------------------------------------------------------------
Comment 170: Clarify flowto
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0069.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-flowto (property) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-flowto>
Status: Alternate action taken
-------------
Your comment:
-------------
ARIA-FLOWTO (role) is an interesting concept. It changes the reading order
of elements. It also allows the author to provide multiple branches for
reading order. If the IDREFs are not meaningful, how will a user know which
branch to take. There should be some mechanism (labeledby?) to provide
human understandable information about the target. Also, what is the UA
supposed to do when the user moves backward in the content? Move to the
previous element in the source? Then the user may get confused, because
information may be presented in a different order moving forward and
backward. Or, is the UA to move to the previous element in the "flow"? In a
large document the branching chain could get very complex. Does the UA need
an additional 'point of flow' tracking mechanism, or can this be handled in
the DOM?
--------------------------------
Response from the Working Group:
--------------------------------
The assistive technology will provide information to the user regarding
which branch to take by following the branch to the target and determining
its text equivalent. Depending on the target, there are numerous vehicles
for naming or labeling it. How to name or label any object is discussed in
the ARIA specification and Best Practices Guide. There is no need to
duplicate the label of the target on the source of the flowto.
Each element in the flowto must have have a unique id. The combination of
the unique id and the name allow the assistive technology to adequately
assist the user in retracing their steps backward through a flow to
reference or moving forward to it. Since the author sets only the target
the user agent is responsible for mapping the backward reference
relationship. Therefore, neither the user agent nor the user can get lost.
If there are a unique ids pertaining to the target objects that are
important to non-impaired users it should be conveyed to all users
otherwise all users would get confused.
The user agent is not required to provide an alternative navigation order
for aria-flowto. We believe this is an assistive technology function and
could in fact be incorporated into a browser or as a plug-in. WAI-ARIA's
task is to ensure the semantics are available to support this alternative
navigation. We believe that has been accomplished.
Your concern for clarity, however, is well taken. After further
investigation of the ARIA Best Practices Guide we conclude that more
information could be provided to describe how a flowto with multiple
targets could be conveyed through an assistive technology to aid users. We
shall provide that information in the ARIA Best Practices Guide.
----------------------------------------------------------------------
Comment 171: Impact of multiline
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0069.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - aria-multiline (property) <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#aria-multiline>
Status: Answered question
-------------
Your comment:
-------------
ARIA-MULTILINE (role) - Who provides some readable/understandable
information to the user indicating the functionality of a 1 character high
input box is equivalent to <input type=text> or <textarea>? Is it the
author, the UA, or UA with AT? This seems to be a repair mechanism to
allow authors to use scripting to alter the behavior of <input> or
<textarea> to be the opposite of expectations, yet still inform (we hope)
the user of the altered functionality. Or, aare we missing something?
--------------------------------
Response from the Working Group:
--------------------------------
As you are aware, each of these elements are mapped to platform
accessibility APIs. WAI-ARIA provides a role="textbox"that may take the
property of aria-multiline to indicate whether it is a basic one line
textbox or whether it is a multi-line text area. ARIA also provides a
property called aria-readonly to indicate whether the element is not
editable. If the author wishes to apply these ARIA properties to a native
text input field they would need to supply the appropriate aria role as
these properties are not global to all host language elements.
By providing these WAI-ARIA properties the author can specify which type
of text input element is being implemented. These base semantics allow user
agents to appropriately map the information to accessibility APIs used on
each of the operating system platforms. This is not meant to be a repair
mechanism. It is meant to convey semantic intent of the author. An
assistive technology will simply convey what is specified by the author.
Should an author wish to visibly convey the revised semantics to all users
there are multiple ways to do this, one being the use of the title
attribute to provide help information. For more lengthy guidance, prose
will work. These reporting techniques are not limited to WAI-ARIA.
----------------------------------------------------------------------
Comment 172: UA for conflicts with host languages
Date: 2009-04-17
Archived at: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0069.html
Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 - 6.1.4. Resolving Conflicts with Host Languages <http://www.w3.org/TR/2009/WD-wai-aria-20090224/#host_general_conflict>
Status: Answered question
-------------
Your comment:
-------------
If host language says one thing, and ARIA says something different, then AT
SHOULD assign preferences to ARIA feature. What should the UA do? There may
be instances where a user is not using AT but still needs access to ARIA
information/functions.
--------------------------------
Response from the Working Group:
--------------------------------
We have changed this section to reference the user agent, which is the host
user agent processing the content. Assistive technology either inherits the
same processing, or is itself a host user agent and subject to the same
processing requirements.
The changes to this section clarify what should happen when ARIA semantics
conflict with host language semantics. There are separate rules for user
agents (which must always respect ARIA role but may ignore ARIA states and
properties when they conflict with corresponding host language features)
and conformance checkers (which may raise errors or warnings as needed).
http://localhost/WAI/PF/aria/20091214/host_languages
Received on Tuesday, 15 December 2009 00:34:42 UTC