Accessibility - Label for Form Elements

[tander08]

Issue: "Form Elements should have a Visible Label"

Resources: https://qdr.syr.edu/qdr-resources

• Search Website Bar under QDR Resources Header

[qqmyers]

Added aria-label="Search Website"

Although - I am confused as to why the Search Data box on the homepage doesn't raise an issue. As far as I can see, the only difference is that that one doesn't have a title, e.g. perhaps the title and placeholder together for the search box on the resources page causes confusion?

[adam3smith]

The search box is getting flagged by Firefox's built-in accessibility check, so I think that's just not getting picked up by Axe for whatever reason. We should add it there, too (can we dynamically do that so there are different labels depending on state?

[qqmyers]

The 'Search Data...' box I'm talking about is the one in the homepage, which doesn't change state. I see that FF raises the same issue for that, the search icon in the header, and the search box that appears when you click that icon. It looks like FF is flagging the literal 'Form elements should have a visible label' whereas Axe says OK if there's an aria-label instead. We'd have to make a visible change in each of those three places, e.g. to add the word 'Search' somewhere nearby to fix it for FF as far as I can tell.

[adam3smith]

I'm pretty sure Axe is right overall. label is preferred where it's possible, but arial-label is acceptable where it isn't.

[adam3smith]

The Search data box on the homepage is now getting picked up by Axe (as is the box in the header...

[qqmyers]

I'm not seeing anything in Axe - is it in a different tool?

[adam3smith]

Yeah, sorry , this is in WAVE again (I thought I had seen it in AXE but apparently not). I think WAVE is correct here, though: I'm not seeing a label or Aria property. Here are the possible fixes it suggests:
A properly associated label is:

• a <label> element with a for attribute value that is equal to the id of a unique form control
• a <label> element that surrounds the form control, does not surround any other form controls, and does not reference another element with its for attribute
• a non-empty title attribute, or
• a non-empty aria-labelledby attribute.

[adam3smith]

More issues with form labels:
This is all testing in Firefox with WAVE (https://addons.mozilla.org/en-US/firefox/addon/wave-accessibility-tool/ )

On dataset creation initial page: https://data.stage-aws-new.qdr.org/dataset.xhtml?ownerId=1

• I'm seeing a number of empty Aria labels. All of those fields have marked labels, so should be fine, but this still seems not ideal? (or maybe doesn't matter?) This is for all standard fields, like title
• Both WAVE and AXE complain about absent labels for the annotations upload fields
• WAVE complains about some additional label-less fields, some of them hidden by CSS. I'm not 100% sure all of these need to be addressed, but let's take a look.
  • The (new?) Host Collection selector at the top
  • The Subject selector box
  • The Browse button for file uploads
  • The Terms of Access text box (hidden)
  • The Provenance JSON Browse button (hidden)
  • The Provenance Description (hidden)
  • The deaccessioning textbox (I think) (hidden)