Open Bug 1678534 Opened 11 months ago Updated 3 months ago

Firefox doesn't transmit value of <option> containing comments

Categories

(Core :: Disability Access APIs, defect)

Firefox 83
All
Unspecified
defect

Tracking

()

People

(Reporter: wkeese, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36

Steps to reproduce:

When a <select>'s selected option contains comments, JAWS, NVDA, etc. won't read the value. From the accessibility tab, we can see that Firefox isn't transmitting a value for the select.

For example:

<select>
<option value="1" selected=""><!---->1<!----></option>
</select>

This is an issue because lit-html inserts comments everywhere.

See the second <select> in https://web-components.carbondesignsystem.com/iframe.html?id=components-pagination--default-story for a working example. (Note that the first <select> is working because it has no comments.)

Actual results:

JAWS, NVDA just announces "combobox"

Expected results:

JAWS, NVDA should announce "combobox 1".

Component: Untriaged → Disability Access
Hardware: Unspecified → All

Confirming this bug. As soon as I expand the combobox with alt+DownArrow, the values are read, and the list items are labeled correctly with their numbers. However, in the collapsed state, the values are empty. Looks like something is throwing off the retrieval of the actual text information between the comment nodes.

Severity: -- → S2
Status: UNCONFIRMED → NEW
Component: Disability Access → Disability Access APIs
Ever confirmed: true
Product: Firefox → Core

Same underlying problem as bug 1667494 with the same required fix (see my comment there for details). This is probably more severe though because while multiple text nodes in an option seems pretty rare and has to be done very deliberately, HTML comments inside an option don't seem that unreasonable.

Blocks: htmla11y
Depends on: 1667494
Keywords: access
QA Whiteboard: qa-not-actionable

This doesn't need the access keyword because it is already in an a11y component. Thanks!

Keywords: access
You need to log in before you can comment on or make changes to this bug.