Modal dialogs should manage keyboard focus, ensuring that users can't
tab out of the modal dialog and back into the page itself (effectively
moving “behind” the dimmed modal). On the last focusable element of the
dialog, return focus back to the first focusable element.
Also move the close button to the start of the dialog's section, making
it the first focusable URL, to ensure focus matches the visual
representation of the dialog.
The close button for the modal dialog was marked up as a paragraph,
containing a graphical text character, inside two div elements, with an
associated click event. This made the button unusable for keyboard
users.
Replaced <divs> with a link element (<a role="button"), adapted the CSS
accordingly, and updated the existing <a> modal close buttons.
Added a 'aria-hidden="true"' attribute to the modal initially, then
toggle the value of that attribute to "false" when the modal is shown.
Also remove the attribute when the modal is closed, whether it's through
a click on the close button or on the overlay.
> To make this change explicit to assistive technology, focus should be
> moved programmatically to this div after it has been made visible. To
> allow the div to be focused via scripting (without adding it to the
> regular focus order that keyboard users cycle through), a tabindex=”-1”
> should be added.
> In addition, the invalid fields should be given a an
> aria-invalid="true" attribute.
Also adding the email description to the login page and applying the
same aria attribute to the correspondin input on that page.
From LMS-602:
> There is additional explanatory text, marked up in a span element after
> the email input. The input elements should be explicitly associated with
> this additional text using the aria-describedby attribute. This will
> require an ID to be assigned to the span element.
Removed extra check for console.log() existance. Modified error
messages. Formatted entire file to fit in 80 lines or less.
Formatting files so that they fit under 80 lines. Adding debug info for
what type of YouTube video player is being used. Also comment on whether
playbackRates is available for HTML5 mode.
Changed back Anton's original function _checkPlaybackRates(). Now logging for
this function's result is done only on error (in the function that is invoking)
it).
