Re: aria-readonly and plain elements

 
Rich Schwerdtfeger




> On Jul 27, 2017, at 12:15 PM, Aaron Leventhal <aleventhal@google.com> wrote:
> 
> I think there need to be some changes to aria-readonly in CORE-AAM and HTML-AAM. The ARIA spec itself is probably fine.
> 
> HTML-AAM currently states: "If the element has the contenteditable attribute and aria-readonly="true", User Agents must expose only the contenteditable state.".
> This doesn't seem right. If an author wants to create their own kind of readonly textfield using JS, they might use <div contenteditable role="textbox" aria-readonly="true"> and then use JS to swallow any input. Why do we specifically disallow this? Also, it is inconsistent with the ARIA spec.

True. Is this a use case you are dealing with? This was new with the latest ARIA in HTML. Steve, is there a reason this use case was not addressed?


I will leave the bottom 2 for Joanie. Did you know that tabindex applies to all elements in HTML - even those in the header? That makes no sense to me either but I fought it and lost. I also lost it in SVG because they wanted to behave like HTML.

> 
> CORE-AAM readonly="false"
> States "Expose IA2_STATE_EDITABLE"
> This does not make sense for a lot of the roles that support aria-readonly, such as a checkbox.
> In general it does not make sense to expose IA2_STATE_EDITABLE unless you also expose the IAccessibleEditableText interface, which you would not do on something like a gridcell unless it had contenteditable.
> 
> CORE-AAM readonly="true":
> Small nit: this could mention that on some elements, aria-readonly may only mapped when there is an ancestor grid (example: rowheader). It probably doesn't matter a great deal though, if the user agent always maps it for those roles.
> 
> Aaron
> 
> 
> 
> On Wed, Jul 26, 2017 at 3:05 PM Rich Schwerdtfeger <richschwer@gmail.com <mailto:richschwer@gmail.com>> wrote:
> Aaron this was in since before 1.0 when you also contributed and reviewed. It has not changed. If you have readonly true the default must be false. That said you know the use cases - grid, treegrid, any control that would allow the user to change it's contents like a UI design tool. There have also been apps that have implemented their own contenteditable at IBM. That said, Caret location is a problem unless you use an OSM. Generally speaking, contenteditable sucks if you wanted to something more involved like Google docs. I am fairly certain Google docs had not used contenteditable as it was not full function enough. They had created special apis for communicating the caret position to their screenreader Chrome add-on. Also, for the longest time Google had only one editor on contenteditable areas and designmode="true".
> 
> Cheers,
> Rich
> 
> Sent from my iPhone
> 
> > On Jul 26, 2017, at 11:32 AM, Aaron Leventhal <aleventhal@google.com <mailto:aleventhal@google.com>> wrote:
> >
> > Aaron