Agreed there's a missing ARIA mapping here, but maybe the value attribute of input row should be split into 2 rows, one for "entry type input elements" and one for "button type input elements"? Then the row for "entry type input elements" could map to aria-valuenow, and (maybe??) the row for "button type input elements" could map to aria-label be "Not mapped", because the mapping for Windows and ATK says:

Associates the accessible value for entry type input elements and accessible name for button type input elements

I also think the input types should be listed explicitly, to eliminate confusion (by making things abundantly clear), e.g.

• button type input elements: submit, image, reset, button
• entry type input elements: text, search, tel, url, email, password, date, month, week, time, datetime-local, number, range, color, file, checkbox?, radio? (not sure if checkbox and radio are entry-type input elements or button-type input elements?)

(I'm ignoring hidden because it has no role and is not mapped, but I don't know if anything needs to be mapped if it has a value?)

As a final note, I see that the mapping for AX just says:

AXValue: <value>

... and I can't help wondering if AX should have the same "value if entry, label if button" mapping text as Win/ATK.
@cookiecrook ^ ?

Edit: Yes, the AX column should say basically the same thing as the other columns (see #314 (comment) below for reasoning):

Associates the accessible value for entry type input elements and accessible name for button type input elements

aria-valuenow is not supported on most of those input elements so currently I'm not sure we would want that mapping on most entry types. I know we have a different issue about the lack of a value attribute in aria w3c/aria#711

Ah, yes - good point. valuenow would only be mapped for number and range.
Interestingly, value for meter and progress is already mapped to valuenow.
The others would want valuetext, as in the issue you pointed to.

So we'd (eventually) need (at least) 3 rows for value attr for input:

• "button type input elements"
• "numeric entry type input elements"
• "text entry type input elements"

Tested what user agents are actually doing with value on inputs.
Test case: https://carmacleod.github.io/playground/value-attr-tests.html
TL/DR: They are mostly doing what HTML-AAM told them to do.

Chrome/Edge/Win:

• button type inputs: value maps to accessible name (and accessible value?) (and is added as visible text content).
  Don't want it mapped to aria-label. Accname doesn't seem to support this? Unless it's covered in step 2D or maybe 2G?
• numeric type inputs: value maps to accessible value (and is added as visible text content or thumb position).
  Ok to map to aria-valuenow because aria-valuenow in CORE-AAM is the same.
• text type inputs: value maps to accessible value (and is added as visible text content) as long as correct format is used (password maps to dots).
  Would be ok to map to aria-valuetext (assuming ARIA role supports attr) because aria-valuetext in CORE-AAM is the same.
• other: cannot set value for file input (value is "No file selected" initially, and is only set in UI), and checkbox/radio value is only used to represent the input for form submission

FF/Win:

• button type inputs: value maps to accessible name (and is added as visible text content).
• numeric type inputs: value maps to accessible value (and is added as visible text content or thumb position).
• text type inputs: value maps to accessible value (and is added as visible text content) as long as correct format is used.
  Except for password, date, time, color (these are set in the UI, but not mapped in the a11y tree - opened FF bug).
• other: as above

Chrome/Edge/FF/Mac: same as their Windows counterparts (above)

Safari/Mac:

• button type inputs: value maps to accessible name (AXLabel for image button, AXTitle for the others) (and is added as visible text content).
• numeric type inputs: value maps to accessible value (and is added as visible text content or thumb position).
  (For slider, value is mapped on thumb, not on slider itself).
• text type inputs: value maps to accessible value (and is added as visible text content) as long as correct format is used (password maps to dots).
• other: as above, except that checkbox/radio accessible value is set to 0 or 1 based on state

@joanmarie Are the ATK mappings basically the same as Chrome/Edge/Win? i.e. the mappings that HTML-AAM specifies?

I am not sure if there is really a bug in Firefox for Date and Time. The input field itself is only the container for the spin buttons in the input field (e.g. for hours and minutes or day, month and year, which get the focus individually and where the value is transmitted correctly). The screen reader NVDA then also correctly determines the value of the container in the element overview (which does not work in Chrome)