Show sign language translation

[greatislander]

• [x] Upload test/sample videos to Vimeo account
• [x] #1256
• [x] Integrate Sign Language options on Accessibility Page
• [x] #1268
• [x] #1257

[greatislander]

From @cherylhjli on #308:

Can turn it on in the web accessibility preferences page: https://www.figma.com/file/AXufBnFAVHvGdsxnQMVhNF/The-Accessibility-Exchange-Wireframes?node-id=2265%3A74852

In-page it will show up as a button you can click to open and close the videos: https://www.figma.com/file/AXufBnFAVHvGdsxnQMVhNF/The-Accessibility-Exchange-Wireframes?node-id=2327%3A63742 https://www.figma.com/file/AXufBnFAVHvGdsxnQMVhNF/The-Accessibility-Exchange-Wireframes?node-id=2327%3A62233

[jobara]

@cherylhjli if I'm understanding the above wireframes correctly:

• The video should appear below the "Sign Language Video" button.
• The video should take up the available width. So depending on which part of the screen the video will be displayed, it may be a different size.
• There could be multiple videos open and potentially playing at the same time

Questions:

• Is the "Sign Language Video" button a toggle button? On first press the video will be shown. On the second press the video will be hidden.
• Will the video autoplay when it opens, or will the user need to explicitly play it?
• Should there be video player controls? e.g. play, pause, stop, etc.
• Have we considered using animated gifs instead of videos?

[cherylhjli]

@jobara

• Depending on the column width, can the max width be around half to 2/3's of the full width of the screen? So if the column is full width like the home page headings, the video can take up half the screen. If the column is already 2/3's width like on the form fields, the video can take up the full column width. Deaf participants have expressed being able to go between written content and signed content easily. If It's full screen it may take quite a bit of scrolling to go between the two.
• Yes the video is a toggle button.
• The user should explicitly play the video. There should be controls.

[jobara]

From today's meeting:

The video should appear below the "Sign Language Video" button.

Yes

The video should take up the available width. So depending on which part of the screen the video will be displayed, it may be a different size.

@cherylhjli will provide specs on size e.g. max-width

There could be multiple videos open and potentially playing at the same time

Should only allow 1 video to play at a time. Preferably a video should also stop after it has been scrolled past. Look at the video's play events to stop other videos and HTML interaction observer to pause when out of view.

Is the "Sign Language Video" button a toggle button? On first press the video will be shown. On the second press the video will be hidden.

Yes

Will the video autoplay when it opens, or will the user need to explicitly play it?

Autoplay for now, but should get feedback from co-designers about preferred experience

Should there be video player controls? e.g. play, pause, stop, etc.

Yes

Have we considered using animated gifs instead of videos?

Seems that an optimized video can be 95% smaller than an animated GIF. See: https://rigor.com/blog/optimizing-animated-gifs-with-html5-video/

Other notes:

• Sign Language Videos are added by section (e.g. HTML section, heading level). @cherylhjli will check with the company to see how they usually provide sign language for forms.
• We want to make it as easy as possible to add in additional sign language videos for the various sections at a later time. @greatislander suggested adding a data attribute to each section so that videos can be dynamically linked later. One thought we had was to use the localization mechanism to provide a key which would include the URL or other identifier to the specific video. The page will add in the sign language link if the localization resolves to an actual value and sign language has been enabled.
• For not will only focus on sign language for the platforms interface/pages. Sign language videos for user content will be explored later.

[cherylhjli]

@jobara Thinking that the max width for the sign language player can be 770px. Hoping for this to be 16x9 in terms of dimensions.

[jobara]

Talked with @greatislander about this some more today. Current idea will be to store the sign language video URLs or IDs in the database along with an identifier generated by a blade/livewire component in the templates. We'll add an admin page that allows an admin to view and modify all of the URLs and link back to where the video will be displayed. Additionally admins will be able to see a button where a video is or can be inserted, which will open an inline edit of the video URL/ID. In this way they can make edits to that on the page where the video will be displayed.

[jobara]

I left some thoughts on the implementation in the Matrix channel.

The gist is generating the section identifiers based off of the slot content is problematic because this content is localized and will be different for the English and French pages. Additionally if localized strings haven't been provided for French when the model is generated, it will store the English text in place which can cause problems later when the French translation is provided.

[jobara]

Talked things over with @greatislander we're going to go with the option of adding a name attribute to the component, with the name taking a localized string that is forced to be in English.

Something like the following:

<x-interpretable-heading :name="{{ __('What is the accessibility exchange?', [], 'en') ">
    <h2 class="align:center" id="what">{{ __('What is the Accessibility Exchange?') }}</h2>
</x-interpretable-heading>

In this way we have a consistent identifier to work from, and it will be included in the localized strings. We can then use the outputted value from the name attribute to re-run through localization when we need to use it to get the translated version as necessary at run time.

[jobara]

An additional consideration is how to provide the link backs to the video locations in context from the admin page when there is a parameter in the URL.

We may be able to find the parameters by doing something like request()->route()->parameters() from the blade component. We'd then need to do some introspection on each parameter to see if they are a string or object.

However, it isn't clear which particular resource we should be linking to from the admin page as these are often tied to a specific user/resource even if the page may visually be the same (e.g. form) for all cases.

Some options:

• create sample/test pages that only an admin can view
  • may need to update other portions of the app so that these pages are leaked to other users or listings pages
  • would need to keep up-to-date with new pages
• find the first instance or use the first record params always
  • would need to ensure that the instance has access to the page (e.g. they've completed other required steps to get there)
  • dangerous if the admin accidentally changes something on an editable page
• don't provide links back for these
  • would remove the ability for users to find where the video is used in context

[jobara]

@greatislander and @cherylhjli, I was going through to add the placeholders for the workflows that were identified for translations. Initially I was just adding the <x-interpretable> component around the <h2> elements. This component essentially creates/finds the model instance for a the sign language video. When a video exists, and the sign language video feature is enabled, the sign language button and video will be appended.

A couple of implementation issues I've run into with workflow 2 which goes through the creation of the public page for an Individual. These are forms with an <h2> at the top and form fields below. In following the wireframes, I was going to add the interpretable component to each input or fieldset. I can wrap a <label>/<x-hearth-label>. However, if the input is a translatable input the label is encapsulated within that component. I could modify those translatable components to always wrap their labels, but we don't have access to the raw localized text, and as such would also need to require that be passed in to the translatable components. Another issue is with <fieldset>'s. It would make sense to wrap the <legend> however, the legend needs to be the first child of the <fieldset> so it cannot be wrapped. I could just put an empty <x-interpretable> component after the <legend> as we don't really do anything with the slot. I'm also thinking now that we don't really need a wrapping component as it will also make it easier to not include on a page when sign language isn't enabled.

@cherylhjli am I adding these to the correct locations on the pages. I guess we'll have more clarity when we hear back from those creating the videos, but does what I've mentioned above seem like the places you were expecting to add the sign language interpretations?