## Description
Updated Greek translation.
## Specific Changes proposed
- Added some missing translations on el.json.
- Updated translations-needed.md.
## Requirements Checklist
- [ ] Feature implemented / Bug fixed
- [ ] If necessary, more likely in a feature request than a bug fix
- [ ] Change has been verified in an actual browser (Chrome, Firefox,
IE)
- [ ] Unit Tests updated or fixed
- [ ] Docs/guides updated
- [ ] Example created ([starter template on
JSBin](https://codepen.io/gkatsev/pen/GwZegv?editors=1000#0))
- [ ] Has no DOM changes which impact accessiblilty or trigger warnings
(e.g. Chrome issues tab)
- [ ] Has no changes to JSDoc which cause `npm run docs:api` to error
- [ ] Reviewed by Two Core Contributors
Co-authored-by: Adam Waldron <acwald@gmail.com>
* remove duplicate icons from icon example
* create initial forward and back button classes
* add logic for back/forward buttons on click
* change icon used based on option passed into player
* move logic from forward and back buttons into one component
* add jsdoc comments for clarity
* create initial test file
* refactor button logic into separate files
* update skip button example and add test files
* test both the forward and backward buttons
* test handleClick fns for both forward and backward btns
* update skip buttons example
* update jsdocs for skip backward and forward buttons
* make control text accessible and use seekableEnd/Start when skipping forward/back
* update font version to use updated icons
* set control text only if config is valid
* add link to sandbox page & use localization
* update translations needed
To make the seek-to-live component more accessible, we hide the text that says "LIVE" from screen readers and make it be purely for sighted users. Then set the control text to be either "Seek to live, currently playing live" or "Seek to live, currently behind live" to indicate what this control does and be informative around whether we are at edge or not. Then use aria-disabled on control if we are at edge.
Restore hidden label text for screen readers that describes what the button control does.
Renames the Duration Time language item to Duration.
Deprecate controlText_ property.
Fix a typo in translations-needed.md.
Add a space in the hidden label for live-display, so that it doesn't run together with the visible "LIVE" indication.
Fixes#5135
This is a first in a few changes related to #4902. This just adds a text alternative to the loading spinner. In future PRs, we would make it alert to screen readers and potentially have a generic alerting mechanism.
It allows you to use string as an key for the language files but have a default value that's different. In this case, we have a key of progress bar timing: currentTime={1} duration={2} which is used so that we have a descriptive key to what is happening. The default value matches that default value in en.json: {1} of {2}. The reason for the default value is so that the translation uses {1} of {2} for the actual localization without requiring en.json to be included in videojs by default.
Fix#4024.
This fixes a lot of the issues from #2746 by making the dialog inherit from our actual ModalDialog which now has tab focus trapping.
The Captions Settings dialog has some accessibility issues:
- Field labels and fields are not explicitly associated
- Keyboard focus does not move into the dialog when it is opened
- Keyboard focus is not trapped inside the dialog while it is open
- Keyboard focus does not return to the control which opened the dialog when it is closed
- The extent (top and bottom) of the dialog is not indicated to screen readers
- The dialog cannot be closed with the Esc key
- The meaning of '---' in the select fields is not clear
- The control to close the dialog is labeled "Done" rather than "Close"
- The purpose of the "Defaults" button may not be obvious, and its effect may not be apparent to screen reader users
- Focus highlighting (outline) on the Default and Done buttons is *very* hard to see
- Pressing the Done button doesn’t seem to have the same effect as pressing the Close (x) button; does it trigger the same focus movement
- This requirement to move it back to the triggering element is tricky, since clicking on that item in the CC menu dismisses the CC menu. I need to think about this a little more - either the menu should open again, or the focus should go to the main CC Menu Button
- The focus outline on the whole dialog goes too far to the left (all the way to the edge of the video window, not just to the edge of the dialog)
Fixes#2746.
