Bug 251544

Summary: AX: input[type=date] individual fields are announced as "group"
Product: WebKit Reporter: Chris <chris.gilardi+webkit>
Component: AccessibilityAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: andresg_22, tyler_w, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: Safari Technology Preview   
Hardware: Mac (Apple Silicon)   
OS: macOS 13   
Attachments:
Description Flags
Incorrect announcement of month input none

Description Chris 2023-02-01 13:06:03 PST
Created attachment 464803 [details]
Incorrect announcement of month input

When using VoiceOver to input text into an input of type "date", the individual text fields (created by the browser for mm/dd/yyyy) are not given human-friendly names, making the field hard to interact with.

When you use the VoiceOver key to select the input, the name assigned to the input *is* announced correctly as "<Aria Label> text, date field", but the internal fields are simply announced as "group."

Example:
<label id="bd-label">Birthdate</label>
<input type="date" aria-labelledby="bd-label"/>

When you tab to the input (which selects the first of the three rendered inputs), Safari simply announces "group". Tabbing to the next two fields produces the same announcement. I have attached a screenshot with what voiceover announces. This example can be found here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date

This is an issue because in a localized environment, users will not be able to tell which field they are interacting with. For example, how would they know which "group" corresponds to Month or Date?

Tested on MacOS 13 Ventura and Safari 16 as well as Technology Preview.

Aside: I am interested in helping fix this issue, if someone could point me in the direction of where such a change may need to be made.
Comment 1 Radar WebKit Bug Importer 2023-02-01 13:06:20 PST
<rdar://problem/104928713>
Comment 2 Tyler Wilcock 2023-02-07 11:49:18 PST
Hi — glad to know you're interested in helping with this one.

Investigating an <input type="date"> with Web Inspector, we see that it's actually implemented with User Agent Shadow DOM elements:

<input type="date">
  Shadow Content (User Agent)
    <div pseudo="-webkit-datetime-edit">
      <div pseudo="-webkit-datetime-edit-fields-wrapper">
        <div pseudo="-webkit-datetime-edit-month-field">02</div>
        <div pseudo="-webkit-datetime-edit-text">/</div>
        <div pseudo="-webkit-datetime-edit-day-field">07</div>
        <div pseudo="-webkit-datetime-edit-text">/</div>
        <div pseudo="-webkit-datetime-edit-year-field">2023</div>
      </div>
    </div>
  End Shadow Content (User Agent)
</input>

And using Accessibility Inspector we can see the accessibility hierarchy for this component. There are several groups in the hierarchy, which probably means WebKit is creating groups for some or all of these divs.

One possible approach for improving this experience is adding some accessible markup to these elements. You can find how they're implemented by searching for them in the WebKit project (e.g. -webkit-datetime-edit-month-field). For example, could we use aria-label to better describe these groups? Are all of these groups really necessary (maybe they are)?
Comment 3 Chris 2023-02-09 14:25:20 PST
Hi Tyler, thanks for your response! Would you happen to potentially have an already-implemented example of this idea somewhere else in the project?

I was able to find the pseudo-elements and where they are created but can't really get my head around how I would programmatically add the `aria-label` attribute. Is there any example of this you can think of that I could look at?

If not, I can keep looking and I'm sure I'll figure it out eventually :)
Comment 4 Tyler Wilcock 2023-02-12 23:24:40 PST
(In reply to Chris from comment #3)
> Hi Tyler, thanks for your response! Would you happen to potentially have an
> already-implemented example of this idea somewhere else in the project?
> 
> I was able to find the pseudo-elements and where they are created but can't
> really get my head around how I would programmatically add the `aria-label`
> attribute. Is there any example of this you can think of that I could look
> at?
> 
> If not, I can keep looking and I'm sure I'll figure it out eventually :)
Hey again Chris. One example you could reference is here where we add an aria-label for a user-agent controlled autofill button element:

https://github.com/WebKit/WebKit/blob/f0420f3bf5b9316e4871996ebda2a1cc0191096a/Source/WebCore/html/TextFieldInputType.cpp#L872

In general, you can find where any attribute is used in WebKit by searching for:

  * "fooAttr" for single-word attributes
  * "foo_barAttr" for multi-word attributes (where the words are separated by hyphen)
Comment 5 Chris 2023-02-17 11:32:58 PST
(In reply to Tyler Wilcock from comment #4)
> (In reply to Chris from comment #3)
> > Hi Tyler, thanks for your response! Would you happen to potentially have an
> > already-implemented example of this idea somewhere else in the project?
> > 
> > I was able to find the pseudo-elements and where they are created but can't
> > really get my head around how I would programmatically add the `aria-label`
> > attribute. Is there any example of this you can think of that I could look
> > at?
> > 
> > If not, I can keep looking and I'm sure I'll figure it out eventually :)
> Hey again Chris. One example you could reference is here where we add an
> aria-label for a user-agent controlled autofill button element:
> 
> https://github.com/WebKit/WebKit/blob/
> f0420f3bf5b9316e4871996ebda2a1cc0191096a/Source/WebCore/html/
> TextFieldInputType.cpp#L872
> 
> In general, you can find where any attribute is used in WebKit by searching
> for:
> 
>   * "fooAttr" for single-word attributes
>   * "foo_barAttr" for multi-word attributes (where the words are separated
> by hyphen)

Hey again Tyler, really sorry to ping again about this.

I have been able to find and update the attributes as you suggested, however, I cannot for the life of me get changes to reflect when running my build with `Tools/Scripts/run-safari`.

I've searched around for fixes to this but haven't really figured out what's wrong. I'm assuming it's some kind of build cache but I can't seem to get it to work.

Here's how I'm testing it (note: my test here is NOT on the date input because i wanted to edit a value I could check more easily):

1. I'm updating line 324 in (Source/WebCore/html/shadow/TextControlInnerElements.cpp)

to `element->setAttributeWithoutSynchronization(roleAttr, HTMLNames::inputTag->localName());`

(I am updating this instance just because it's a little easier for me to reliably test. Once I get it changing here I will be able to more reliably test my changes to the date input).

2. I run `Tools/Scripts/build-webkit --debug`
2a. The build succeeds with: "** BUILD SUCCEEDED ** [1571.372 sec]"

3. I run `Tools/Scripts/run-safari --debug`.
4. I go to this url: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/search
4a. I enter some text in the "Search the site" box so the X button comes up
4b. Using the Accessibility Inspector, I check that X button. Its role should be "input" but it still shows as "button"

Any ideas about how to get these changes to reflect? Again, I apologize if this is just my lack of knowledge of the project/build tooling.

Thanks again for your time.
Comment 6 Tyler Wilcock 2023-02-17 11:41:17 PST
(In reply to Chris from comment #5)
> (In reply to Tyler Wilcock from comment #4)
> > (In reply to Chris from comment #3)
> > > Hi Tyler, thanks for your response! Would you happen to potentially have an
> > > already-implemented example of this idea somewhere else in the project?
> > > 
> > > I was able to find the pseudo-elements and where they are created but can't
> > > really get my head around how I would programmatically add the `aria-label`
> > > attribute. Is there any example of this you can think of that I could look
> > > at?
> > > 
> > > If not, I can keep looking and I'm sure I'll figure it out eventually :)
> > Hey again Chris. One example you could reference is here where we add an
> > aria-label for a user-agent controlled autofill button element:
> > 
> > https://github.com/WebKit/WebKit/blob/
> > f0420f3bf5b9316e4871996ebda2a1cc0191096a/Source/WebCore/html/
> > TextFieldInputType.cpp#L872
> > 
> > In general, you can find where any attribute is used in WebKit by searching
> > for:
> > 
> >   * "fooAttr" for single-word attributes
> >   * "foo_barAttr" for multi-word attributes (where the words are separated
> > by hyphen)
> 
> Hey again Tyler, really sorry to ping again about this.
> 
> I have been able to find and update the attributes as you suggested,
> however, I cannot for the life of me get changes to reflect when running my
> build with `Tools/Scripts/run-safari`.
> 
> I've searched around for fixes to this but haven't really figured out what's
> wrong. I'm assuming it's some kind of build cache but I can't seem to get it
> to work.
> 
> Here's how I'm testing it (note: my test here is NOT on the date input
> because i wanted to edit a value I could check more easily):
> 
> 1. I'm updating line 324 in
> (Source/WebCore/html/shadow/TextControlInnerElements.cpp)
> 
> to `element->setAttributeWithoutSynchronization(roleAttr,
> HTMLNames::inputTag->localName());`
> 
> (I am updating this instance just because it's a little easier for me to
> reliably test. Once I get it changing here I will be able to more reliably
> test my changes to the date input).
> 
> 2. I run `Tools/Scripts/build-webkit --debug`
> 2a. The build succeeds with: "** BUILD SUCCEEDED ** [1571.372 sec]"
> 
> 3. I run `Tools/Scripts/run-safari --debug`.
> 4. I go to this url:
> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/search
> 4a. I enter some text in the "Search the site" box so the X button comes up
> 4b. Using the Accessibility Inspector, I check that X button. Its role
> should be "input" but it still shows as "button"
> 
> Any ideas about how to get these changes to reflect? Again, I apologize if
> this is just my lack of knowledge of the project/build tooling.
> 
> Thanks again for your time.
No need to apologize! Seems like you're doing everything right. For future reference, I'd recommend asking any build related questions in the public WebKit Slack, either in the #help or #dev channels. You can join that here:

https://join.slack.com/t/webkit/shared_invite/enQtOTU3NzQ3NTAzNjA0LTc5NmZlZWIwN2MxN2VjODVjNzEyZjBkOWQ4NTM3OTk0ZTc0ZGRjY2MyYmY2MWY1N2IzNTI2MTIwOGVjNzVhMWE

This document is also helpful if you haven't seen it already:

https://github.com/WebKit/WebKit/blob/main/Introduction.md#introduction-to-webkit

Accessibility Inspector (comes with Xcode installations) is also a very useful tool when working on these types of bugs.

---

My guess as to the problem here is that you're trying to set an ARIA role of "input", but that's not a valid ARIA role, and therefore it's ignored. The existing code on line 324 is:

element->setAttributeWithoutSynchronization(roleAttr, HTMLNames::buttonTag->localName());

Which is going to compute to "button", which *is* a valid ARIA role.

The list of ARIA roles are here:

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques#roles.
Comment 7 Chris 2023-02-22 15:02:58 PST
Pull request: https://github.com/WebKit/WebKit/pull/10546
Comment 8 EWS 2023-03-03 01:12:59 PST
Committed 261123@main (d4f4aedd0656): <https://commits.webkit.org/261123@main>

Reviewed commits have been landed. Closing PR #10546 and removing active labels.