{"id":966,"date":"2024-01-12T17:05:46","date_gmt":"2024-01-12T17:05:46","guid":{"rendered":"https:\/\/html5accessibility.com\/stuff\/?p=966"},"modified":"2024-02-08T11:53:29","modified_gmt":"2024-02-08T11:53:29","slug":"options-for-optgroup-labeling-of-options","status":"publish","type":"post","link":"https:\/\/html5accessibility.com\/stuff\/2024\/01\/12\/options-for-optgroup-labeling-of-options\/","title":{"rendered":"options for optgroup labeling of options"},"content":{"rendered":"

\"philosoraptor<\/p>\n

An ugly truth is that there are still interoperability issues with some of the native HTML controls and Screen readers. Even though these controls have been around since long before AI came to the rescue of our accessibility asses<\/em>.<\/p>\n

A case in point is the expression of option<\/code> group labels, AKA (Also Known As) <optgroup label=\"poot\"><\/code> What is exposed in the accessibility tree for <select size=\"1\"><\/code> and size=>1<\/code> still differs in some browsers (i.e. Chrome)<\/p>\n

Chrome size=1<\/h2>\n

<select><\/code> exposed as a combobox<\/code>,\u00a0 <optgroup><\/code> is not exposed, there is a MenuListPopup<\/code>\u00a0containing the 4 menuitem<\/code>‘s<\/p>\n

\"Snippet<\/p>\n

Chrome size=>1<\/h2>\n

<select><\/code> exposed as a listbox<\/code>, each <optgroup><\/code> is a group<\/code> with child options, the <optgroup><\/code> label<\/code> attribute value is used as the accessible name for the group.<\/p>\n

\"screenshot<\/p>\n

Firefox size=1<\/h2>\n

The representation for the select<\/code> does expose the optgroup<\/code> element’s as group<\/code>‘s in the accessibility tree, unlike<\/em> Chrome.
\n\"a<\/p>\n

Firefox size=>1<\/h2>\n

<select><\/code> exposed as a listbox<\/code>, each <optgroup><\/code> is a group<\/code> with child options, the <optgroup><\/code> label<\/code> attribute value is used as the accessible name for the group.<\/p>\n

\"The<\/p>\n

Frigging about<\/h2>\n

I frigged about<\/em> with the code, what I wanted was to have JAWS and NVDA to announce the group<\/code> labels along with the option<\/code> labels, regardless of the browser and select size<\/code> and state, in the case of size=\"1\"<\/code> (on desktop browsers) the select<\/code> can be operated (using the keyboard) in the collapsed or expanded state. In fact JAWS advises the user to interact with the control in the collapsed state (which is helpful as I would later realise). When a closed select<\/code> receives focus it announces “combobox, to change the selection use the arrow keys”.<\/p>\n

When in the collapsed state, neither JAWS or NVDA announce the group labels. For some reason when in the expanded state in Firefox, JAWS does not<\/strong> announce the group labels, but it does recognize that the option’s are divided into groups…. NVDA does<\/strong> announce as expected.<\/p>\n

\"Collapsed<\/p>\n

\"a<\/p>\n

Unfortunately even in the case where the group labels are exposed<\/em>\u00a0in the Chrome accessibility tree (in the size=>1<\/code> case), they are not announced by JAWS or NVDA. I suspect this is due to some property not displayed in the Chrome dev tools accessibility tree, which is causing them to be ignored as they are announced in Firefox, (by NVDA) when the popup is displayed. This is acknowledged by Google acc engineers<\/a> as a gap in Chrome’s support.<\/p>\n

The outcome of the code frigging<\/h2>\n

I found that I needed to add aria-label<\/code><\/a> to each option<\/code> which included both the optgroup label<\/code> and the option label<\/code>, by doing so the information was announced consistently by NVDA and JAWS\u00a0 in Chrome and Firefox.<\/p>\n

Of course this is not ideal<\/em> as it requires the addition of ARIA and the duplication of the group label. But the exercise was not about theoretical purity of things working as they should, but about how to convey the information to screen reader users as it is to others.<\/p>\n

Using the aria-label<\/code> on the option<\/code> element with both the optgroup<\/code> and option<\/code> labels as content, provides robust support across browsers and screen readers:<\/p>\n

<optgroup label=\"fruits\">\r\n<option aria-label=\"fruits apple\"<\/mark>>apple\r\n<option aria-label=\"fruits pear\"<\/mark>>pear\r\n<\/optgroup><\/pre>\n
Too much effort?<\/h3>\n
It should be<\/em> relatively simple to implement via post rendering scripting if necessary, the automated addition of the aria-label<\/code>‘s using the labels already present in the DOM.<\/p>\n
I asked ChatGPT to create a script to do just that, as a proof of concept. It provided me with the following:<\/p>\n
javascript:(function() {\r\ndocument.querySelectorAll('select').forEach(select => {\r\nselect.querySelectorAll('optgroup').forEach(optgroup => {\r\nconst groupLabel = optgroup.getAttribute('label');\r\nif (groupLabel) {\r\noptgroup.querySelectorAll('option').forEach(option => {\r\nconst optionLabel = option.getAttribute('label') || option.textContent;\r\noption.setAttribute('aria-label', `${groupLabel}: ${optionLabel}`);\r\n});\r\n}\r\n});\r\n});\r\n})();<\/pre>\n
try it on for size<\/h3>\n
See the Pen 
\nUsing JavaScript to polyfill group labelling support<\/a> by steve faulkner (@stevef<\/a>)
\non CodePen<\/a>.<\/p>\n