- 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 UTC