Bugzilla

> - Changing this to a group role has a few unintended consequences -- mainly that we no longer announce this as a "date time field" and instead we call it a "group". This is because we no longer get the role description for free. We can override that and call into the date time role description [with something like this](https://searchfox.org/mozilla-central/rev/4d2b1f753871ce514f9dccfc5b1b5e867f499229/accessible/mac/MOXWebAreaAccessible.mm#35). We'd need to [create a new accessible class](https://searchfox.org/mozilla-central/rev/4d2b1f753871ce514f9dccfc5b1b5e867f499229/accessible/mac/mozActionElements.h#57-65) (moxDateTimeAccessible probably) which inherits from mozAccessible and overrides moxRoleDescription. FWIW I'm pretty sure this is what safari does, since they expose date time inputs as AXTextFields but still get the role description right. 
> - VO is pretty picky when it comes to tree structure, so it's possible the problem isn't so much the role but the way we've structured the mac a11y tree inside elements with AXDateField as their role. In Safari, for ex, the controls are rendered in a group element instead of as direct children of the input itself. It's possible this role/tree structure combo is necessary for VO to be able to get to elements within an input field with an AXTextField role. 
> - Considering these two solutions, the latter is probably more correct but we'd have to do a decent amount of testing and tree manipulation to verify the tree structure is even a factor. I'm happy with using a group role and overriding role description for now. If this is a change you feel comfortable making, go for it :) happy to answer any questions you have about implementation. Also happy to take this on since this is something outside of your purview. Let me know what you think!

Thank you very much for researching this issue, @morgan!

It looks like the core of the issue does fall into the platform side of code which is outside of my expertise and experience. I'm abandoning the revision, but I will move the comments that you've left to the Bugzilla bug for future reference for another assignee.

Morgan did a huge research on the source of the unexpected behavior and has provide the following feedback [on the now-obsolete patch in Phab](https://phabricator.services.mozilla.com/D167854#5532889):

> - Changing this to a group role has a few unintended consequences -- mainly that we no longer announce this as a "date time field" and instead we call it a "group". This is because we no longer get the role description for free. We can override that and call into the date time role description [with something like this](https://searchfox.org/mozilla-central/rev/4d2b1f753871ce514f9dccfc5b1b5e867f499229/accessible/mac/MOXWebAreaAccessible.mm#35). We'd need to [create a new accessible class](https://searchfox.org/mozilla-central/rev/4d2b1f753871ce514f9dccfc5b1b5e867f499229/accessible/mac/mozActionElements.h#57-65) (moxDateTimeAccessible probably) which inherits from mozAccessible and overrides moxRoleDescription. FWIW I'm pretty sure this is what safari does, since they expose date time inputs as AXTextFields but still get the role description right. 
> - VO is pretty picky when it comes to tree structure, so it's possible the problem isn't so much the role but the way we've structured the mac a11y tree inside elements with AXDateField as their role. In Safari, for ex, the controls are rendered in a group element instead of as direct children of the input itself. It's possible this role/tree structure combo is necessary for VO to be able to get to elements within an input field with an AXTextField role. 
> - Considering these two solutions, the latter is probably more correct but we'd have to do a decent amount of testing and tree manipulation to verify the tree structure is even a factor. I'm happy with using a group role and overriding role description for now. If this is a change you feel comfortable making, go for it :) happy to answer any questions you have about implementation. Also happy to take this on since this is something outside of your purview. Let me know what you think!

Thank you very much for researching this issue, @morgan!

It looks like the core of the issue does fall into the platform side of code which is outside of my expertise and experience. I'm unassigning myself from the bug but including the feedback from Phab here for future reference for a future assignee.

Morgan did a huge research on the source of the unexpected behavior and has provide the following feedback [on the now-obsolete patch in Phab](https://phabricator.services.mozilla.com/D167854#5532889):

> - Changing this to a group role has a few unintended consequences -- mainly that we no longer announce this as a "date time field" and instead we call it a "group". This is because we no longer get the role description for free. We can override that and call into the date time role description [with something like this](https://searchfox.org/mozilla-central/rev/4d2b1f753871ce514f9dccfc5b1b5e867f499229/accessible/mac/MOXWebAreaAccessible.mm#35). We'd need to [create a new accessible class](https://searchfox.org/mozilla-central/rev/4d2b1f753871ce514f9dccfc5b1b5e867f499229/accessible/mac/mozActionElements.h#57-65) (moxDateTimeAccessible probably) which inherits from mozAccessible and overrides moxRoleDescription. FWIW I'm pretty sure this is what safari does, since they expose date time inputs as AXTextFields but still get the role description right. 
> - VO is pretty picky when it comes to tree structure, so it's possible the problem isn't so much the role but the way we've structured the mac a11y tree inside elements with AXDateField as their role. In Safari, for ex, the controls are rendered in a group element instead of as direct children of the input itself. It's possible this role/tree structure combo is necessary for VO to be able to get to elements within an input field with an AXTextField role. 
> - Considering these two solutions, the latter is probably more correct but we'd have to do a decent amount of testing and tree manipulation to verify the tree structure is even a factor. I'm happy with using a group role and overriding role description for now. 

Thank you very much for researching this issue, @morgan!

It looks like the core of the issue does fall into the platform side of code which is outside of my expertise and experience. I'm unassigning myself from the bug but including the feedback from Phab here for future reference for a future assignee.

Morgan did a huge research on the source of the unexpected behavior and has provided the following feedback [on the now-obsolete patch in Phab](https://phabricator.services.mozilla.com/D167854#5532889):

> - Changing this to a group role has a few unintended consequences -- mainly that we no longer announce this as a "date time field" and instead we call it a "group". This is because we no longer get the role description for free. We can override that and call into the date time role description [with something like this](https://searchfox.org/mozilla-central/rev/4d2b1f753871ce514f9dccfc5b1b5e867f499229/accessible/mac/MOXWebAreaAccessible.mm#35). We'd need to [create a new accessible class](https://searchfox.org/mozilla-central/rev/4d2b1f753871ce514f9dccfc5b1b5e867f499229/accessible/mac/mozActionElements.h#57-65) (moxDateTimeAccessible probably) which inherits from mozAccessible and overrides moxRoleDescription. FWIW I'm pretty sure this is what safari does, since they expose date time inputs as AXTextFields but still get the role description right. 
> - VO is pretty picky when it comes to tree structure, so it's possible the problem isn't so much the role but the way we've structured the mac a11y tree inside elements with AXDateField as their role. In Safari, for ex, the controls are rendered in a group element instead of as direct children of the input itself. It's possible this role/tree structure combo is necessary for VO to be able to get to elements within an input field with an AXTextField role. 
> - Considering these two solutions, the latter is probably more correct but we'd have to do a decent amount of testing and tree manipulation to verify the tree structure is even a factor. I'm happy with using a group role and overriding role description for now. 

Thank you very much for researching this issue, @morgan!

It looks like the core of the issue does fall into the platform side of code which is outside of my expertise and experience. I'm unassigning myself from the bug but including the feedback from Phab here for future reference for a future assignee.