Map fieldset readonly state to accessibility

[teoeter]

Related spec PR: whatwg/html#12424
Spec issue: whatwg/html#10293

The HTML spec is gaining a readonly content attribute on <fieldset>
that propagates a read-only state to descendant form controls that
support being readonly — mirroring how disabled already works.

HTML AAM currently maps the disabled state of a fieldset's descendants
to aria-disabled (or the platform equivalent). The readonly state on
those same descendants should presumably map to aria-readonly (or
platform equivalent), but I'd like to confirm:

1. Should a descendant <input>/<textarea> that is read-only due to
   the fieldset expose aria-readonly=true (or the platform AX
   readonly state)?
2. Should the <fieldset> itself expose any readonly state to AT, or
   only its descendants? (The fieldset has no aria-readonly mapping
   today.)
3. Are there any platform AX APIs where a "readonly group" concept
   exists and we should map it differently?

Filing this so HTML AAM can be updated alongside the HTML spec change

[scottaohara]

@teoeter if this is trying to mimic the behavior of marking a fieldset as disabled, i would submit that some of your questions are answered from how that behaves.

the caveat here being is that currently a role=group (what a fieldset currently is) cannot be marked as readonly in ARIA. Last I checked, the state isn't respected / does not cascade down to its descendent form controls. Unlike disabled, not all form controls can be set to an explicit readonly state either... so what is the expectation there, since that would diverge from author expectations based on how the disabled attribute works?