Page MenuHomePhabricator

[Spike] Identify accessibility and internationalization requirements for simple components in Vue.js search
Closed, ResolvedPublicSpike

Description

Imagine that the initial iteration of the few Vue.js components needed for the new search experience were written. E.g., those components might include a button, thumbnail, and a header. The structure of those components may seem sane but, if you had to write an overarching task to assess them for their accessibility and internationalization capabilities, what would be the criteria by which you would judge them? That's what this task is to identify. It's a meta-task to create at least one more task to assess the component criteria identified in this task.

What about larger compositions of components like the entire SearchForm and the UniversalLanguageSelector? How should those interact and be evaluated? An even simpler example: tabbing handling in several components from different software projects in a view/on a page. What are the guidelines? This task can't effectively cover those complex (yet common) use cases. There also questions like how does a Vue instance in search interact with a Vue instance in Special:ContentTranslation and does it need to? Assessing these important and more involved scenarios is out of scope for this task but should be a pressing consideration.

Requirements identified

  • The design is responsive for all screen sizes.

Acceptance criteria

  • At least one new task is made for the component assessment.
  • Any Storybook or styling requirements are mentioned in the task(s). E.g., WMDE and ContentTranslation use addons/a11y.
  • The criteria at least cover the needs of the test wikis (T249297).
  • The new task(s) contain the success criteria identified in this task. That is, if a given component meets each criterion, it is ready to ship from a i18n and accessibility point-of-view.
  • a11y and i18n accessibility subject matter experts are consulted. We have a number of specialists including: @Mooeypoo, @Volker_E, @Jdrewniak, @Nikerabbit, and @santhosh. It's ok for this process to be iterative but we need to get very strong initial guidelines. It's also ok for these discussions to create more tasks.
  • Does WMDE have any guidelines for their components?
  • Criteria are documented on wiki as best practice thoroughly including examples.

Event Timeline

Restricted Application changed the subtype of this task from "Task" to "Spike". · View Herald TranscriptApr 3 2020, 3:24 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
ovasileva triaged this task as Medium priority.Apr 3 2020, 8:27 AM
Niedzielski renamed this task from [Spike] Identify accessibility and internationalization requirements for components to [Spike] Identify accessibility and internationalization requirements for components in Vue.js search.Apr 5 2020, 4:22 PM

I'm concerned that when looking at a single component we might set ourselves up for missing trans-component issues and requirements. Simple example: Tabbing handling in several components from different software projects in a view/on a page.

Niedzielski renamed this task from [Spike] Identify accessibility and internationalization requirements for components in Vue.js search to [Spike] Identify accessibility and internationalization requirements for simple components in Vue.js search.Apr 15 2020, 12:17 AM
Niedzielski updated the task description. (Show Details)

Noting some i18n issue that come to mind:

Font-size & line height across different language fonts
The typeahead suggestion box usually has an associated max-height, which is designed to fix a certain amount of text without cutting it off . That height varies across languages, so we have to pick a font-size & line-height that accommodate the broadest range of languages.

RTL support, in combination with an eventual language picker
CSSJanus takes care of most RTL concerns, but if we want to include a language picker beside the search box, what happens when someone switches the search from English to Arabic? Will the search input, along with the search-suggestion items switch to RTL? (p.s. I just noticed this does not happen on www.wikipedia.org)

(I think a storybook instance would be excellent for visualizing the search box across languages).

In regards to a11y, my instinct says that the search-suggestions should be invisible to screen-readers, as they could be very interruptive, but it would be nice if they were keyboard accessible (maybe using arrow keys?)

@Jdrewniak I've been considering your wikipedia.org implementation as the definitive reference with feed in from the other implementations you identified. /cc @holger.knust

The typeahead suggestion box usually has an associated max-height,

Maybe I am misunderstanding your point but is this true? Consistent line height sounds good but I don't see any kind of truncation done on the suggestion container. E.g., check out the height of "Digital object identifier" as compared to "D":

(p.s. I just noticed this does not happen on www.wikipedia.org)

What is the ideal behavior? Flipping the results but not the rest of the form?

(I think a storybook instance would be excellent for visualizing the search box across languages).

+1!

maybe using arrow keys

That sounds nice to me. I saw similar advice here.

The typeahead suggestion box usually has an associated max-height,

Maybe I am misunderstanding your point but is this true? Consistent line height sounds good but I don't see any kind of truncation done on the suggestion container. E.g., check out the height of "Digital object identifier" as compared to "D":

haha your right there is no line clamping! 😅 I guess as far as I got with that was writing this comment (but I think that decision is probably more design oriented than i18n or a11y).

@Jdrewniak @Volker_E it seems some of this is done? Can acceptance criteria be marked as done where it's done and could work done be summarized?
I would like to understand what's left and if it's a blocker for closing out T249298

I think the a11y concerns have been thoroughly considered in the search typeahead implementation (I think it may be a good idea to get an a11y audit of this feature after it's been deployed, but I think that's a separate task?). The i18n considerations have also been addressed by using the https://www.npmjs.com/package/vue-banana-i18n plugin, and RTL flipping will be handled by ResourceLoader when the feature will be integrated into Vector.

So we can resolve and create a task to do an a11y audit?
I assume that should be a subtask of T240489 ?

ovasileva added a subscriber: ovasileva.

@Volker_E - resolving this for right now to make space on the board. Feel free to add any thoughts and re-open if necessary when you have time for a review.