Hyrax: Swap Column Order of Search Results

[mtribone]

Descriptive summary

In Hyrax 2.0.0 alpha, we code the columns of the search results as we see them visually. For screen readers and the document hierarchy, it would be better to swap the columns and put the content of the search results before the facets.

Rationale

As users of assistive technology skim or tab through the content of the page, they are looking for content. Since they've performed a search, let's give them the search results _before_ the facets.

Expected behavior

Being able to get to the content easily and quickly using assistive technology.

Actual behavior

A lot of tabbing through the interface to get content

Steps to reproduce the behavior

1. Use VoiceOver to tab through a search
2. Or use a screen reader

Related work

https://github.com/samvera/hyrax/issues/1263

https://github.com/psu-stewardship/scholarsphere/issues/582
https://github.com/psu-stewardship/scholarsphere/pull/614

[jcoyne]

@mtribone If the user wants to find "Books" that were "authored by Kant, Immanuel" wouldn't they first be looking for the filters? Have you tested this scenario?

[ggeisler]

Maybe an alternative to swapping section order is adding skip link(s) so the screen reader user can just jump past facets when not needed to get to the main content?

[mtribone]

@jcoyne Wouldn't they need to do a search first and read the results before they filter? Yes. Tested with one user who works for Central IT and is visually impaired. @ggeisler I think the <main> element might be useful, too.

[jcoyne]

Wouldn't they need to do a search first and read the results before they filter?

No, they wouldn't. They know they don't have the filters set, so they know any results are rubbish.

[metageeky]

mtribone is right. General best practice is to put main content before side content. Even if it's on the left of the main content, reading order should general go:
HEADER
MAIN CONTENT
LEFT SIDEBAR
RIGHT SIDEBAR
FOOTER
http://www.accessiq.org/create/content/reading-order-and-focus-order-accessibility-for-developers

This applies for both screen reader accessibility and keyboard navigation.

Skip links are not really a great option because even if they become visible when tabbed to, the visual cue to keyboard users is that they would have tab through all the filters first. Screen readers have other options to jump between parts of a page as well.

[metageeky]

If the user wants to find "Books" that were "authored by Kant, Immanuel" wouldn't they first be looking for the filters? Have you tested this scenario?

@jcoyne That is a very specific search scenario which I do believe you are right in that filters before results in the DOM optimizes the UI. However, not all search scenarios will be as specific. The user might be searching a more general topic and upon interpreting the results will then choose to filter.

[atz]

Isn't there a blacklight configuration for facet-side? (I know there is in VuFind.) If so, this is just a configuration issue, and not a Hyrax code problem.

[metageeky]

@atz Even if there is, I suspect the solution would move the facets to the right column visually. That is not what we are talking about. Regardless of where the columns appear visually, the best accessibility practice is to arrange the DOM in the following order (using the div IDs found in app/views/catalog/index.html.erb:

SEARCH_RESULTS
SEARCH_SIDEBAR

CSS is then used to place the facet sidebar on whichever of the two sides is desired.

[adamjarling]

@no-reply @vantuyls @chrisdaaz After reading this discussion thread, what's the acceptance criteria for this issue? Move the facets sidebar into a right-column?

[mtribone]

@adamjarling Yeah the facets sidebar goes to the right in _the code_ and then use Bootstrap to _push_ the column visually to the left.

We have a working example in ScholarSphere
https://github.com/psu-stewardship/scholarsphere/blob/develop/app/views/catalog/index.html.erb

Notice the classes for the column widths and where to place the columns visually.

[adamjarling]

Thanks for the tip @mtribone . This one is fixed as well and waiting on build updates.