RE: aria-readonly questions

Hi Jonathan,

in generell you are right and that was the way the web was initially designed to
be. But the web is always in movement.
A rich internet application often supports patterns where a dialog is in a
read-only mode and therefore input fields are readonly.
Then there is an edit button that switches the fields to editable.

Using disabled has many undesired effects such as:
* The input fields are greyed out - for some widgets it is impossible to change
this via CSS.
* Users of screenreaders can not easily read the content while in readonly mode.

If you instead use readonly, users of screenreaders can still tab through the
fields and read the values of the form.
Then they can decide if they want to edit or if everything is fine already just
as a seeing user would do.
But screenreaders currently read these fields as editable ("edit") what is
technically wrong and there is no way to
express this with WAI ARIA if you also want to specify an according role such as
combobox.

HTML5 changed towards the direction that common attributes are now allowed
everywhere instead only in specific elements.
For ARIA it is worth to think about this trend as well. That is why I also think
that the spec should tell screenreader implementors to use
standard HTML attributes and states such as readonly and disabled as fallback if
not overriden with the more specific aria-* attribute.

I seriously want to challenge the current ARIA spec and IMHO it should be
changed.

Regards
  Jörg

> 
>    * Why is aria-readonly only applicable for gird, gridcell and textbox?
> 
> 
> 
>  Read-only is intended to allow the user to review the contents via the
> keyboard but not edit the element.  This is different from disabled.  When
> something is disabled it is not typically in the tab order.   In non-web
> software applications read-only was used to allow screen reader access to edit
> fields that were not editable where disabled would have prevented access
> completely.  My guess is other controls could simply be disabled and provide
> the same level of access but read-only may be needed to instruct user agents
> to still provide keyboard access but block editing.
> 
> 
> 
>  Jonathan
> 
> 
> 
> 
> 
>  From: "Jörg Hohwiller" [mailto:joerg@j-hohwiller.de
> <mailto:joerg@j-hohwiller.de> ]
>  Sent: Friday, January 11, 2013 3:38 PM
>  To: w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org>
>  Subject: aria-readonly questions
> 
> 
> 
>  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
> <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
> <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
>