Skip to content

Plans regarding attribute parity

Jump to bottom
joanmarie edited this page Nov 14, 2019 · 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, poster, preload, rel, rows, sandbox, shape, sizes (on link), slot, srcdoc, srclang, target, title (on link, style), translate, type, usemap, value, wrap

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

Already done via AccName

alt, label, title

Already done via ARIA

  • checked: aria-checked

  • colspan: aria-colspan

  • disabled: aria-disabled

  • hidden: aria-hidden

  • indeterminate: aria-checked=mixed

  • max: aria-valuemax

  • min: aria-valuemin

  • multiple (on select): aria-multiselectable

  • selected: aria-selected

  • placeholder: aria-placeholder

  • readonly: aria-readonly

  • required: aria-required

  • rowspan: aria-rowspan

  • scope=col: columnheader role

  • scope=row: rowheader role

  • value (on meter, progress): aria-valuenow

Already "done" via exposure of rendered result

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

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

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

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

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

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

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

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

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

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

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

TODO During 1.3

  • high on meter

  • low on meter

  • 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?

  • abbr on th

  • cite on blockquote, del, ins, q

  • cols on textarea

  • contenteditable

  • datetime on del and ins

  • datetime on time

  • dir

  • headers on td and th

  • href on a, area

  • list on input

  • lang

  • open on details

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

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

  • span (on colgroup)

  • src on img

  • step on input

  • value on li

These need further discussion:

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

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

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

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

  • maxlength on input, textarea: not mapped. But maybe it should be?

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

1.3 Planning

Tracking issue: FPWD

Clone this wiki locally