Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recommended fields for search/filtering in the user experience #196

Closed
rickj opened this issue Oct 30, 2023 · 22 comments
Closed

Recommended fields for search/filtering in the user experience #196

rickj opened this issue Oct 30, 2023 · 22 comments

Comments

@rickj
Copy link
Collaborator

rickj commented Oct 30, 2023

As a followup to our email conversation after TPAC, here is the sub-list of items that were identified for searching/filtering:

  • Any accessible information (any of the a11y metadata fields have content)
  • Conformance information (dcterm:conformsTo)
  • Certification information (a11y:certifiedBy)
  • Accessible Math (MathML) (accessibilityFeature = MathML)
  • Supports Visual Adjustments (accessiblityFeature = displayTransformability)
  • Supports nonvisual reading (accessModeSufficient = textual )

with an open question for: 'do not search/filter on hazards, but it may be critical to always be able to show the presence of claimed hazards in any search/filter return'

@gautierchomel
Copy link
Collaborator

From France feedback we had:

Facets: A small set of properties has been extracted as a first proposal:

  • File format
  • Reflowable
  • Fixed layout
  • Fully rendered as text
  • Fully rendered as audio
  • Synchronized text and audio
  • Print-equivalent page numbering
  • EPUB Accessibility - WCAG AA conformant

@gautierchomel
Copy link
Collaborator

This aspect may be even more affected by public target of the portal / retailer. We'll need a minimal set and an extended proposal.

@rickj
Copy link
Collaborator Author

rickj commented Nov 1, 2023

I believe a minimal set should be focused on discovery, with extended set examples, or recommended details that should be displayed in the search/filter result given for specific markets.

What I mean by 'discovery' is an answer to a user trying to find a book, and would a specific item stand alone as a search/filter term, or would it be presented in the results of that search/filter?

Examples: Would a user say "Show me only items where _______ is true" and does this make sense for:

  • show me only items that have conformance information (I think: yes)
  • show me only items that have print-equivalent page numbering (I think: no, but I would want this displayed in the result of other searches/filters)

@gregoriopellegrino
Copy link
Collaborator

Thank you for these proposals. To me "Accessible Math (MathML)" is very important for the school sector, it seems less significant in the trade sector. What do we include in the minimal set?

@rickj
Copy link
Collaborator Author

rickj commented Nov 2, 2023

My thoughts about the context for this discussion was to provide recommendations for narrowing the list of potential metadata items (more than 70 possibilities!) that might be used to narrow down a search/filter (and avoid a very complicated user interface to support all those). I was thinking:

  • A user is coming to a site/application for discovery and is presented with a search/filter interface
  • There are some 'non accessibility' metadata items that a user may input for their search/filter (author, title, ISBN, ...), and there are some 'non accessibility' metadata items that they would expect to see presented in the search/filter results (price, publisher, ...)
  • The same is true for accessibility metadata items:
  • There are some things they would want to use to narrow the result list down to a reasonable size (is there any a11y metadata claims at all?, has someone certified the a11y markup?, does it claim to conform to a standard? Does it support some of the major accommodation needs (visual adjustments, non-visual reading)
  • There are some a11y metadata that may be more appropriate to view when looking at a specific title (hazards, ...)

The question about MathML (or any chart, diagram, formula metadata claims) is "would I use this to narrow down a search/filter, or would I want to view this in the result/detail?". I agree this is probably sector specific... but MathML would be a recommendation for many.

@clapierre
Copy link
Collaborator

For conformance this could get tricky, due to all the WCAG levels and versions. Something like a minimum of XYZ ie. WCAG 2.0 AA, which then would imply WCAG 2.1 AA, and WCAG 2.2 AA would also be acceptable.

@rickj
Copy link
Collaborator Author

rickj commented Nov 2, 2023

@clapierre I agree, the complexity here would be signifiant. My thought for a search/filter recommendation would be a boolean for most things. In other words "show me titles where some conformance claim was made, and results of the search/filter could display columns of what's in there, or a user could view detail (whatever the app/site implements).

@clapierre
Copy link
Collaborator

I agree having a yes/no for conformance would be useful but some folks maybe required to have at least a specific WCAG version / level requirement say for example my school district requires all materials we procure must meet WCAG 2.1-AA status, having something like this could be very useful.

@rickj
Copy link
Collaborator Author

rickj commented Nov 2, 2023

There's that 'meet' word again! Just what does that mean!! :-)

@gautierchomel
Copy link
Collaborator

gautierchomel commented Nov 15, 2023

The draft proposal for discovering section of the UX guide can be consulted as HTML.

(edit: updated the url)

@avneeshsingh
Copy link
Collaborator

avneeshsingh commented Nov 21, 2023

The filters are quite implementation specific, depending on the audience. If we want to nail down some least common denominators or minimum set, the I see the following as the key information which would be present in all implementations.

  • Support for non-visual reading.
  • Support for visual adjustments
  • Conformance and certification.

The filters like file type, audio books etc. can be the part of generic filters. These help in determination of accessibility but may not be coming specifically from accessibility metadata.

My suggestion is to state in the principles document that our research for filters is work in progress. We recommend to use at least the above listed filters.

Then in the implementation section, we show how VitalSource is using filters, how LIA is using filters, how retailers in France are using filters and so on.

For the minimum set, it would be helpful to know if there are filters in addition to the three that I mentioned above.

@GeorgeKerscher
Copy link
Collaborator

I totally agree with Avneesh.

@gregoriopellegrino
Copy link
Collaborator

+1 to Avneesh

@gautierchomel
Copy link
Collaborator

If we have to stick with a minimum guidance I find Rick's proposal Any accessible information more pertinent than conformity. Conformity adresses national legislations but does not tel me that I can use the book in an academic context (because it has print page numbers).

I propose that we don't keep Complete filtering example but stand with Minimum (reading modes + a11y info available) and intermediary (minimum + conformity + pagenumber). Then rewrite 4.1 to 4.6 filtering per categories sections for a 2 sections structure explaining the rationals for minimum and intermediary + a note that every value can be used in a complete filtering scenario.

@HadrienGardeur
Copy link

HadrienGardeur commented Nov 28, 2023

At De Marque, we've been pushing for the following options while browsing and searching in our catalogs:

  • Natively accessible (for WCAG AA publications)
  • Adjustable text and layout (accessiblityFeature = "displayTransformability")
  • Supports screen-readers and read aloud feature (accessModeSufficient = "textual")
  • Full recorded audio (accessModeSufficient = "auditory")

While we've been thinking about individual features, it felt too granular to be widely useful for our audience.
This is currently deployed in our marketplace (where we sell content to libraries) and in our portal used by public libraries. We're also about to roll out support for a11y metadata and such filters in our portal for schools (primary and secondary education).

For higher education, we're considering adding additional features such as:

  • Print-equivalent numbering (accessiblityFeature = "printPageNumbers")
  • Described math (accessiblityFeature = "describedMath")

Based on our experience, users are not aware of the differences between a reflowable and a fixed layout EPUB. Some of them are barely aware of the differences between a PDF or an EPUB, and I personally believe that talking about the ability to change the font size (displayTransformability) might be easier to understand for everyone, not just users who need specific accessibility features.

@rickj
Copy link
Collaborator Author

rickj commented Nov 29, 2023

After the discussions with people in London, and several others, I would like to modify my original proposal.

We will be grouping metadata into 9 key accessibility areas. These should provide our guidance on recommended search/filtering options.

Specifically, for searching and filtering return a simple boolean yes/no flag for:

  • Is there information in ANY of the categories

Is there information in one of these specific categories:

  • Supports Nonvisual Reading
  • Visual Adjustments
  • Navigation
  • Charts, Diagrams, and Formulas (i.e. Math)
  • Hazards
  • Conformance
  • Pre-recorded audio

As Accessibility Summary and Additional accessibility information are free form text, those may be considered 'optional'.
I would also point out that specific implementations may decide to be more granular, such as also calling out Certifications, which are part of the conformance category, but may provide value to some markets

@gautierchomel
Copy link
Collaborator

gautierchomel commented Nov 30, 2023

Here is a proposal summarizing the actual state of the discussions:

Minimum filtering set

Book selling or lending platforms usually have a lot of filtering options, limiting the additions could become an important factor. This reality should not impeach users with specifics reading needs to find books that they can read. To achieve that goal, the ways of consuming the content are key informations that should always be present in filtering. This informations are non visual reading and visual adjustments. Only the positive values should be used for filtering. In addition, it is recommended to allow the possibility to find all the publications that have at least one accessibility information available.

examples

  • Supports Nonvisual Reading
  • Supports Visual Adjustments
  • Accessibility information available

Extended filtering set

In specific contexts, the addition of filtering options will become important to help users find content that responds to particular obligations or scenarios. Each specific scenario should drive the selection of appropriate filters. In this section, we enlighten the main cases we've been confronted with or that have been reported to us. This list is not exclusive.

  • In an academic context, the presence of printed page numbers will be crucial to make sure the reader will be able to find a reference indicated in another book or make one in its own work.
  • In the academic context again, the information about ways provided to access complex contents like Charts, Diagrams, and Formulas has a strong importance because it would determine if the
  • In markets where the selection of references is submitted to legislation, the conformity information becomes mandatory.
  • Platforms dedicated to selling children's books and interactive content should pay attention to allowing users to select books with no hazards. They may also want to inform about the presence of pre-recorded audio.

examples

  • Page list
  • Charts, Diagrams, and Formulas
  • Minimum accessibility standards (A)
  • Accepted accessibility standards (AA)
  • No hazards
  • Pre-recorded audio

@rickj
Copy link
Collaborator Author

rickj commented Dec 6, 2023

Well done. Some suggested edits:

Minimum filtering set

Reading systems, commerce, and distribution platforms will typically have specific filtering options; having uniformity for key aspects and providing guidance for a standardized approach can help the discovery process for users searching relevant titles. Accomplishing this, however, should not prevent users with specifics reading needs finding books they are looking for. To achieve that goal it is recommended that all platforms present three minimum capabilities, centered around the ways of consuming the content. These are:

  1. Discovery of all titles with any accessibility metadata available
  2. Titles that support non visual reading
  3. Titles that support visual adjustments.

Of note, only the positive values should be used.

Extended filtering set

In specific domains, the addition of other options will become important to help users find content that responds to a particular need or scenarios. Each domain case would uniquely drive the selection of appropriate items. Some examples of these domains (not exclusive) are:

  • In an academic context, the presence of printed page numbers may be crucial to make sure the reader will be able to find or make a reference.
  • In a technical or scientific context, the information about ways provided to access complex contents like Charts, Diagrams, and Formulas would have a strong importance to know if accessibility markup were present.
  • In markets where compliance to legislation is required, understanding conformity information becomes mandatory.
  • Platforms dedicated to selling children's books and interactive content may want to allow users to select books with no hazards, or inform about the presence of pre-recorded audio.

gautierchomel added a commit that referenced this issue Dec 11, 2023
@avneeshsingh
Copy link
Collaborator

Hans Beerens from Dedicon has suggested the following in the minimum set. Thanks to Gautier for reaching out.

  • text/audio synchronisation
  • dyslexia readability
  • fixed lay out/reflow
  • TOC navigation
  • possibly hazards.

Reading this list I realized that we have an important use case missing from the extended set. It is the libraries serving the people with disabilities.

@gautierchomel
Copy link
Collaborator

This may be addressed in a one line addition to the Extended filtering set section:

  • Libraries serving the people with disabilities will certainly want to provide readability adaptation specifics filtering option related to content presents in they're collections like text/audio synchronisation or dyslexia readability.

@HadrienGardeur
Copy link

Based on our experience with schools in Québec, we see that text/audio synchronization (Media Overlay in EPUB) is useful for almost every young reader, not just those with specific needs.

We could almost say the same about what we label as "Supports screen-readers and read aloud feature" (aka "Non-visual reading") since it's by far the most popular feature for schools.

In public libraries, it remains popular but it's behind other features such as:

  • Adjustable text and layout (displayTransformability)
  • Table of contents (tableOfContents)
  • and bookmarks (available in schema.org but this is a reading system feature rather than a publication one)

@gautierchomel
Copy link
Collaborator

During dec. 14th call we discussed the utility and risks of Discovery of all titles with any accessibility metadata available as it may return ebooks that have "accessibility unknown", "non accessible" or all titles because they all have a TOC. Also, technically implementing this filtering may become tricky as it means to grab more than 40 informations.

We agreed to keep "Accessibility information available" out of the minimum filtering set recommendation and add a note detailing this.

We should also consider adding accessmode Sufficient for auditory (the entire text is pre-recorded audio).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants