Plans regarding attribute parity

• Introduction
• Parity not planned
• Already done via AccName
• Already done via ARIA
• Already "done" via exposure of rendered result
• TODO During 1.3
• Candidates for 1.3 (Mapped on at least one platform)

Introduction

This triage is based on what is in the HTML-AAM. Joanie did not go through the HTML spec looking for attributes that are in there, but not in the HTML-AAM. It would be great if someone could do that.

Parity not planned

These are not mapped on any platform: accept, accept-charset, action, allow, allowfullscreen, allowpaymentrequest, as, async, autocapitalize, autofocus, autoplay, charset, class, color, content, crossorigin, data, decoding, default, defer, dirname, download, enctype, form, formaction, formenctype, formmethod, formnovalidate, formtarget, href (on link), hreflang, http-equiv, id, ismap, kind, loop, media, method, multiple (on input), muted, name, novalidate, ping, playsinline, poster, preload, referrerpolicy, rel, rows, sandbox, shape, sizes (on link), slot, srcdoc, srclang, target, title (on link, style), translate, type, usemap, value (on button, option, param, data), wrap

In addition, these will not be done for the stated reason:

1. controls on audio, video: We are not creating audio and video roles at this time. See https://github.com/w3c/aria/issues/517. Therefore attribute parity for roles which do not exist makes no sense.

Already done via AccName

alt, label, title

Already done via ARIA

1. checked: aria-checked

2. colspan: aria-colspan

3. disabled: aria-disabled

4. hidden: aria-hidden

5. indeterminate: aria-checked=mixed

6. max: aria-valuemax

7. min: aria-valuemin

8. multiple (on select): aria-multiselectable

9. selected: aria-selected

10. placeholder: aria-placeholder

11. readonly: aria-readonly

12. required: aria-required

13. rowspan: aria-rowspan

14. scope=col: columnheader role

15. scope=row: rowheader role

16. value (on meter, progress): aria-valuenow

Already "done" via exposure of rendered result

1. coords on area: Exposure to ATs should come from rendered object; not the property.

2. height on canvas, embed, iframe, img, input, object, video: Exposure to ATs should come from rendered object; not the property.

3. reversed on ol: Exposure comes via the text exposed for the list item markers.

4. size on input: Exposure based on bounding box rendered widget.

5. size on select: Exposure based on rendered widget (similar to type on input).

6. sizes on img, source: Exposure to ATs should come from rendered object; not the property.

7. start on ol: Exposure comes via the text exposed for the list item markers.

8. style: Exposure to ATs should come from the rendered/calculated styles.

9. tabindex: Exposure mostly done via focusability (when not -1). We also have coverage by managing keyboard focus spec contents.

10. type on ol: Exposure comes via the text exposed for the list item markers.

11. width on canvas, embed, iframe, img, input, object, video: Exposure to ATs should come from rendered object; not the property.

TODO During 1.3

1. high on meter

2. low on meter

3. optimum on meter

Candidates for 1.3 (Mapped on at least one platform)

Do ATs really need these? If so, can we get mappings for all platforms?

1. abbr on th

2. cite on blockquote, del, ins, q

3. cols on textarea

4. contenteditable

5. datetime on del and ins

6. datetime on time

7. dir

8. headers on td and th

9. href on a, area

10. list on input

11. lang

12. open on details

13. pattern on input (current mapping is for the presence of error; not the pattern itself)

14. spellcheck on input (current mapping is for the presence of error; not if checking is enabled)

15. span (on colgroup)

16. src on img

17. step on input https://github.com/w3c/aria/issues/471

18. value on li

These need further discussion:

1. accesskey: Do we have sufficient parity through aria-keyshortcuts?

2. autocomplete: Need to get/update mappings for UIA, AXAPI. In addition, in HTML values are on/off. ARIA lacks these.

3. draggable: not mapped. Question: Do we want to deal with drag and drop during 1.3?

4. for on label and output: Can this be covered via aria-labelledby?

5. maxlength on input, textarea: not mapped. But maybe it should be? Joanie thinks so.

6. minlength on input, textarea: not mapped. Also maybe it should be?

7. type on button: Exposure mainly based on label. But see also https://github.com/w3c/aria/issues/842

8. type on input: Exposure based on rendered widget. But see also https://github.com/w3c/aria/issues/962

9. value on input: Exposure comes via the text/value exposed as the content of the input.