Improve form accessibility

[Atticus29]

Description

• Following the compliance subtask list, I have begun applying <label> tags to form fields.

• Sometimes, this entailed adding id attributes to form fields.

• I added i8n in a few files where translated documents already existed (e.g., foo.en.php, foo.es.php, and foo.fr.php).

• If forms existed with multiple columns of form fields, I simplified them where possible such that form fields all fell within one column. This was done 1) to ease the burden on people using screen readers and 2) to ease the burden on people with dyslexia and/or ADHD.

• I caught a few uses of FILTER_SANITIZE_STRING (which will be deprecated for PHP v.8.0+) and changed them to htmlspecialchars(foo, HTML_SPECIAL_CHARS_FLAGS).

• In a few areas, if I happened to see a button or input element using an image, I added an alt attribute.

• In a few forms, for instance ones with ranges (x to y), I added explicit labels for the beginning and end ranges (or start and end dates). This was done 1) to ease the burden on people using screen readers and 2) to ease the burden on people with dyslexia and/or ADHD.

One file to pay particular attention to would be ../collections/harvestparams.php, as that form was changed quite a bit and reflects a lot of what I've read about best practice so far.

What is not in this PR

This PR is meant essentially to be a gut check that I'm on the correct track in terms of the changes that I'm implementing. It is nowhere close to inclusive of all of the changes to come (e.g., vocal form validation, form field highlighting, etc. etc.). Please refer to the compliance subtask list for the full list.

Pull Request Checklist:

• Features and backlog bugs should be merged into the Development branch, NOT master
• Hotfixes should be merged into both the Development and master branches (at the same time).
  • NA
• All new text is preferrably internationalized (i.e., no end-user-visible text is hard-coded on the PHP pages)
  • I also internationalized a few existing sections, but not comprehensively
• There are no linter errors
• New features have responsive design (i.e., look aesthetically pleasing both full screen and with small or mobile screens)
• Symbiota coding standards have been followed
  • Small exceptions where I added inline styling in a few places. I plan on looping back around and fixing this as development for 508 compliance continues.
• If any files have been reformatted (e.g., by an autoformatter), the reformat is its own, separate commit in the PR
• Comment which GitHub issue(s), if any does this PR address
  • NA

TODO

• It is the code author's responsibility to merge their own pull request after it has been approved
• If this PR represents a merge into the Development branch, remember to use the squash & merge option
• If this PR represents a merge from the Development branch into the master branch, remember to use the merge option
• If the dev team has agreed that this PR represents the last PR going into the Development branch before a tagged release (i.e., before an imminent merge into the master branch), make sure to notify the team and lock the Development branch to prevent accidental merges while QA takes place

Thanks for contributing and keeping it clean!