Labels for certain form fields are not announced by JAWS

This appears to be an issue for all select forms. The first option in the list is being read instead of the label.

Is there an upstream issue we should point to in Chrome?

Seems like it might be a browser specific, or even release specific bug.

There is no upstream issue that I am aware of. But yes, this does appear to be a Chrome specific issue.

@findleys - can you submit a bug report and provide a link here? I didn't see something quite right here, but just took a quick look.

https://bugs.chromium.org/p/chromium/issues/list?can=2&q=Labels+jaws&col...

Re: #3, announcing the fieldset legend. I'm not particularly worried about that. I've read reports that screen readers vary quite a lot about how they announce the legend name. Sometimes they announce the legend along with every field in the fieldset, sometimes they announce it once upon entering the fieldset. I saw a chart of this somewehere in the last few years. Not sure if I can find it again. I've certainly heard how NVDA announces the legend when entering the fieldset by tabbing forwards, but not when entering the fieldset by shift-tabbing backwards.

From issue summary, original report...

The defect exists in Google Chrome v54.0.2840.99 m and does not exist in IE 11.

The label is announced with IE, but not Chrome, using the same screen reader, but different browsers? That's sounds like it's down to a difference in what the browser exposes to the platform accessibility APIs. Then again who knows with JAWS - it also gets stuff directly from the browser DOM too, if it can. Maybe we could check what they send to the accessibility tree, using aViewer.

In #3, by this time you say you're using Chrome 61, and...

a combo box field called “Title” combo within the Contact Information is accessed, JAWS announces, “Title combo box –None- 1 of 7”.

Well that sounds like Chrome 61 + JAWS is indeed announcing the label correctly. You're mainly concerned with the fieldset legend there.

Chrome is up to version 65 now. This is worth testing again to see if it's still an issue with JAWS.

I tested the filters at the top of admin/content using Win7 + NVDA v2018.1 - the selects were announced with the label, role, current value, and collapsed state. "Combobox, Content type, collapsed, Basic Page." This worked with IE11, Firefox 52 ESR, and Chrome 65. So no issue there. I'm confident that we're providing all the semantics in a machine readable way, and this comes down to quirks with particular combinations of browser and screen reader.

Minor edit to the issue summary. <label> wasn't being displayed, so I deleted the angle brackets for clarity.

There's another detail I noticed. The original report says that the content screen has select elements where "-View all-" is announced. That's odd because the select elements on the admin/content page have "- Any -" as the option name, after installing the standard profile.

Is it possible the Drupal site being tested had a customized content listing? If so, are the labels correctly associated with the select elements?

I tested some fieldsets in Drupal core. On the account settings page, there are two fieldsets containing radio buttons, with legends. One is about who can register an account, the second is about what happens to a user's content when an account is cancelled.

I tested with Windows 7, NVDA v2018.1, IE 11, Firefox 52 ESR, and Chrome 65.

In all 3 browsers, the legend was announced on entering the fieldset by pressing tab, but the legend was not announced when changing from one radio button to another with arrow keys.

I tried moving further though the form, then returning to the fieldsets by pressing shift-tab to go backwards. On entering the fieldsets, the legends were announced with Firefox and Chrome.

On IE 11 + NVDA 2018.1 + Win 7, there is an odd quirk:

• When entering the fieldset by tabbing forward, the legends were announced.
• When entering fieldsets by shift-tabbing backwards, the legend was consistently announced for one fieldset, but consistently NOT announced for the other.
• The difference is that one fieldset contained radio buttons only, but the other fieldset had radio buttons, followed by a text description div containing a link.
• It seems that when entering a fieldset and landing on a radio button, the legend is announced. But when entering a fieldset and landing on a link, the legend is not announced. This is the kind of quirk that's beyond our control.

I'm going to park this one for now, after the investigations above. There's nothing actionable for us, unless we hear more detail about the behaviour of JAWS with current browser versions.

When providing more detail, we'd like to know as much of the following as possible:

• The versions of Drupal, Windows, JAWS, and browsers.
• The URL path of the Drupal page. So far I've assumed that "Content screen" meant admin/content. Correct me if that's not the case.
• Whether you are testing a fresh installation of Drupal standard profile, some contrib installation profile or distro, or a specific website that your organization has built.
• In the latter case, please provide as much information about the form as you can. Javascript components, custom templates, contrib/custom modules involved, whatever you know.
• The specific label, field type, and names of options that you are expecting to hear. This is about comment #12, where I noted a discrepancy between the "-View all-" text in the report, and Drupal's default text which is "- Any -". This made me suspect the report was about a form that had been customized somehow. (Nothing wrong with that, just useful to know).

Closing this one. I've asked for more information, and none has been provided.

See comment #10 particularly. I noted the discrepancy between the original report for Chrome 54 (select label not announced) and the later report for Chrome 61 (comment #3, which says the select label is announced).

Announcing the fieldset legend for every control inside a fieldset is a pipe dream. Screen readers vary in their approach to that, and it isn't something that Drupal should try to force IMO.

I revisited this one because it cropped up on the #bugsmash channel in Drupal Slack.

Note that "section 508" is a USA-specific regulation. The accessibility maintainers don't have any interest in country-specific regulations; there are just too many countries! It's not the target of the core accessibility gate; we use the WAI recommendations.