quoted from
https://www.accessibility-developer-guide.com/examples/sensible-aria-usage/expanded/
As a general rule, the toggled element should be right below the toggle
button, so screen readers will find it easily. If that is not the case,
then the focus should be placed inside the element upon toggling it
visible, and back to the initial element upon toggling it invisible.
The initial focused element should be the first operator button.
This commit also fixes the accessibility issues that previously were
wrongly fixed by a redundant click on the first tab using javascript.
After a major upgrade was done in h5p.com, some random errors appeared
in the "H5P options are ignored for H5P URLs" scenario.
They have been fixed replacing the URL for different (which should
load quicker). As we're checking external content, no other improvement
can be done on the Moodle site.
The table button can become a menu button when the cursor's position
in the editor is within a table. So we'd need to update the button with
ARIA attributes appropriate for a menu button.
This is best done when the button's highlight gets toggled, so we're
adding an event listener for when this happens and add/remove the ARIA
attributes accordingly.
The `types` object introduced in Moodle 3.11 has been replaced with the
`eventTypes` object which is used consistently across all CustomEvent
definitinos.
Likewise the trigger functions have been renamed from
`triggerUploadStarted` to `notifyUploadStarted` and from
`triggerUploadCompleted` to `notifyUploadCompleted`.
Backwards compatability is maintained.
This just deletes all the upgrade steps previous to 3.6.0. Some
small adjustments, like tweaking globals can also be applied
when needed.
Also includes an upgrade step to prevent upgrading from any
version < 2018120300 (v3.6.0) as anti-cheating measure.
Note that in this case, there wasn't any case of upgradelib
functions being used, hence we haven't to deprecate/remove
anything in codebase. When there is such a need, that is done
in separate commits (one for each function) and documented here.
See MDL-65809 commits for an example removing/deprecating a
good number of functions.
version = 2021052500 release version
requires= 2021052500 same than version
Why 20210525? (25th May 2021) ?
Because master is going to be Moodle 4.0, to be released
on November 2021. And, until then, we are going to have
a couple of "intermediate" releases:
- Moodle 3.10 to be released 9th November 2020. (2020110900)
This version will be using versions from today to 2020110900
(once it's released the YYYYMMDD part stops advancing).
- Moodle 3.11 to be released 10th May 2021. (2021051000)
This version will be using versions from 3.10 release to 2021051000
(once it's released the YYYYMMDD part stops advancing).
That means that all versions from today to 2021051000 are going
to be used by those 2 "intermediate" releases (3.10 and 3.11).
And we cannot use them in master, because it's forbidden to have
any overlapping of versions between branches (or different upgrade
paths will fail).
So, get that 2021051000, let's add it a couple of weeks to cover
the on-sync period (or a 2 weeks delay max!) and, the first version
that master can "own" in exclusive (without any overlap) is, exactly,
25th May 2021, hence our 20210525.