View mode switch accessibility

[doana]

Description

Use more semantically appropriate elements for list controls and markup that better aligns with WCAG recommendations.

Instructions for Reviewers

This issue originally brought to my attention because our accessibility auditing tools flag the links as having empty link content. While in practice they read fine to me in my testing using the NVDA screen reader, other assistive technology might not infer that the icon title should be used as the link text.

The crux of this change is to use more semantically appropriate elements for the view mode switch controls. The use of button elements is more appropriate as they don't imply a significant change of context the way that a link element does. The other change here is to explicitly include the name for the control in the button element itself, instead of as part of the title attribute on the icon inside of the link. This better aligns with the WCAG since the name of the control is more explicitly available for programmatic access.

List of changes in this PR:

1. Use buttons instead of links for the controls
2. Move the name of the control outside of the icon title attribute and into the body of the button element
3. Use span for the icon elements as the idiomatic text element doesn't make semantic sense for an icon
4. Update tests

An alternative strategy for #2 would be to set the title element on the button itself, rather than on the icon. This would keep the tool tip that is lost from this change.

Checklist

This checklist provides a reminder of what we are going to look for when reviewing your PR. You need not complete this checklist prior to creating your PR (draft PRs are always welcome). If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!

• My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
• My PR passes ESLint validation using yarn lint
• My PR doesn't introduce circular dependencies (verified via yarn check-circ-deps)
• My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
• My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
• If my PR includes new libraries/dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
• If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself.
• If my PR fixes an issue ticket, I've linked them together.

[tdonohue]

👍 Thanks @doana for your contribution! I was able to test this today and verified that there are no adverse side effects to the behavior of these buttons. I agree completely that your fixes are more appropriate and improve accessibility.