Address UX feedback on location-based search form

[jazairi]

Note to reviewer: this has not yet passed QA. I was hoping to complete UXWS review before merging, but I'd like to start working on advanced search form updates that are likely to cause merge conflicts with this PR.

Why these changes are being introduced:

This is in response to a UX review of location-based search.

Relevant ticket(s):

• GDT-136

How this addresses that need:

• Removes top margin from all details elements except the first.
• Bolds labels.
• Moves placeholder text to description span elements and changes "e.g." to "Ex:".
• Changes language for distance description/hint.
• Changes summary labels for geobox and geodistance.
• Removes red asterisks as indicators of required classes, and instead adds a p tag indicating as much below each legend.

Side effects of this change:

None.

Developer

• All new ENV is documented in README
• All new ENV has been added to Heroku Pipeline, Staging and Prod
• ANDI or Wave has been run in accordance to
  our guide and
  all issues introduced by these changes have been resolved or opened as new
  issues (link to those issues in the Pull Request details above)
• Stakeholder approval has been confirmed (or is not needed)

Code Reviewer

• The commit message is clear and follows our guidelines
  (not just this pull request message)
• There are appropriate tests covering any new functionality
• The documentation has been updated or is unnecessary
• The changes have been verified
• New dependencies are appropriate or there were no changes

Requires database migrations?

NO

Includes new or updated dependencies?

NO

[coveralls]

Pull Request Test Coverage Report for Build 8443128519

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 98.872%

---

Totals
Change from base Build 8441357913:	0.0%
Covered Lines:	526
Relevant Lines:	532

---

💛 - Coveralls

[JPrevost]

As noted on Slack, I think we should keep the asterisks as the "all fields in this section" type wording is very likely to be overlooked and most people are familiar with the asterisk usage. If UX disagrees, I won't block on that but I do want to make sure we check in with them on that.

Andi warns that the label for the fields may not be marked up correctly. I suspect this should be resolved but I'm fairly early into my coffee.

warning[Element nested in <label> but label[for=basic-search-main] does not match element [id=geobox-minLongitude].](https://www.ssa.gov/accessibility/andi/help/alerts.html?nested_label_for_no_match)

There is some odd keyboard navigation and screen reader behavior in our expandable forms we may want to address (possibly beyond MVP). I'll note the concern here but it is not blocking on this ticket. We should investigate whether we should move the search button to below the form elements. Having it inline means you reach it before you have tabbed through all of the expanded form elements and before you might notice that there are unexpanded form elements that may be of interest. I think this should be a new ticket but noting here so I don't forget to check in with you on whether this has previously come up.

[jazairi]

@JPrevost Good point about moving the search button to the end. I hadn't thought about that, and I suspect it's necessary.

I'm seeing that warning in ANDI, too, for every geo and advanced field. (I'd been running WAVE, which doesn't mention it.) I'm a little confused by it, because none of those fields are actually nested in the basic search label. However, that label is an empty tag, and none of the others are, so maybe that's what is throwing ANDI off?

[jazairi]

@JPrevost Yep, just confirmed locally that we can clear up the ANDI warnings by marking up the label like this: <label for="basic-search-main" class="field-label"><%= label %></label>.

In this case, I removed the text from the label and used the title attribute since the purpose of the input is clear to sighted users, but screen reader users need context. However, I think the correct path here is to put the title attribute in the input and remove the label altogether. That also removes the ANDI warnings. It does raise a WAVE warning, but the context makes it sound like we're good:

The title attribute value for unlabeled form controls will be presented to screen reader users. However, a properly associated text label provides better usability and accessibility and should be used unless the purpose of the form control is intuitive without the label.

[jazairi]

@JPrevost I added the asterisks back in with a key, made a couple other CSS tweaks, and removed the empty label element. (The title attribute is now on the input, which ANDI likes but WAVE doesn't -- see my comment above.)

I also opened this ticket to explore options for the search form submit button. I added it to the post-MVP epic for now. I'd strongly prefer to complete it before then, but I'm not sure how realistic that is with the sprint ending in a few days. I'll put that on Darcy's radar, as well.

Let me know if there are any other changes you'd like to see here. Thanks for the detailed review!