I don't know how bad that is in practice: https://a11ysupport.io/tests/html_label_element_implicit
...but it does look worse than explicit: https://a11ysupport.io/tests/html_label_element_explicit
> Whenever possible, use the label element to associate text with form elements explicitly
> [..]
> In some situations, form controls cannot be labeled explicitly... Generally, explicit labels are better supported by assistive technology
...but people have been saying that for like 15 years now, I don't know how big of a deal those failures are. That'd be a good blog post
If some company makes a shoddy half baked solution for sale (looking at you, Dragon), and they don’t understand basic HTML that has been standardized for years, that’s not my problem. The same way I don’t only use the subset of web technologies that the AOL Premium web browser supports for $10 bucks a month.
I think the implication is these voice control programs aren't using the accessibility tree built by the browser but parsing the DOM themselves, poorly. It's not really surprising for Dragon since it does hardly anything in a browser without its browser extension installed and extensions don't have access to the accessibility tree. It's more surprising for macOS Voice Control.
[1] https://www.freedomscientific.com/products/software/jaws/
[2] https://webaim.org/blog/jaws-license-not-developer-friendly/