W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2013

aria-readonly questions

From: Jörg Hohwiller <joerg@j-hohwiller.de>
Date: Fri, 11 Jan 2013 21:38:07 +0100 (CET)
To: w3c-wai-ig@w3.org
Message-ID: <1293565458.228861.1357936687724.JavaMail.open-xchange@webmail.strato.com>
Hi there,

I am new to this mailing list and want to get into discussion.

As an open-source developer I am creating yet another (however very different)
web-framework and have implemented the WAI ARIA.
For those who want to have a look, here is the link:
https://github.com/m-m-m/mmm/tree/master/mmm-client/mmm-client-ui/mmm-client-ui-core/mmm-client-ui-core-api/src/main/java/net/sf/mmm/client/ui/api/aria
Feedback is very welcome.

While dealing with ARIA and testing with JAWS and NVDA some questions came up.
To give the discussion a clear focus I start with aria-readonly.
http://www.w3.org/TR/wai-aria/states_and_properties#aria-readonly

* Why is aria-readonly only applicable for gird, gridcell and textbox?
  E.g. a combobox can also be readonly. Screenreaders seem to strictly stick
with this and read my comboxes
  as "edit" even if in readonly mode with aria-readonly set to true in HTML.

* Some other Web-Frameworks such as SmartClient define roles for input elements
in screenreader mode.
  For input elements there is already the HTML attribute readonly that is
normaly honored by screenreaders.
  However, if the role attribute is set, the screenreaders start to ignore the
readonly attribute and
  only react to aria-readonly. Shouldn't the existing HTML attributes be honored
and additional aria attributes
  only used to override this? How about setting role on input elements at all?

Thanks & best regards
  Jörg
Received on Friday, 11 January 2013 20:38:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 11 January 2013 20:38:32 GMT