Skip to content

Plans regarding attribute parity

Peter Krautzberger edited this page Jan 24, 2022 · 21 revisions

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

  1. high on meter

  2. low on meter

  3. optimum on meter

Candidates (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 https://github.com/w3c/aria/issues/472 [closed / rejected (for now)]

  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 [closed / rejected (for now)]

  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.