Only a handfull of images remain without alts. Some help centre articles have images without alt, but due to embedded nature of the product, students will rarely interact with these parts.

See rationale below. We've adjusted this to 80% as we don't support adding additional audiotracks as an alternative, or the options to download the transcripts. After adding the option to download the transscripts, we'll adjust this to 95% compliant as this is above industry standard.

We provide support for adding closed captions as is expected from the spec. But we are neither responsible or currently capable of creating these closed captions ourselves. Educational staff should provide these with the course content they upload. Considering we currently cover the criterion above industry standard, we've given ourselves 95% compliance. In the long future we still want to extend on this by providing the student with the ability to easily add their own closed captions, or apply AI to facilitate automatically generated captions when not present in the audio/video (to go from 95% to 100% coverage)

1.2.3 – Audio Description or Media Alternative (Pre-recorded)

Almost everywhere the case, some exceptions remain. Page sections are structured with subheadings (with appropriate HTML tags), structural elements have appropriate HTML tags, forms are clearly labeled. Regularly an element is inappropriately nested tho.

Navigation is clearly separated from content. Content sequencing is appropriate. Regularly an element is inappropriately nested so it doesn't pass W3C’s markup validator tho.

There's a very small amount of empty-state and onboarding illustrations and copywriting left that rely on position-on-screen, like arrows pointing towards a component, or descriptions of a button position like "bottom left". These can always also be discovered through alternative means.

Colorcoding is always accompanied by explanations, ability to get those, or other characteristics (shape, location, icon) that by association reveals meaning.

Time-based mechanics can always be paused. Only exception is time-limited questions on Interactive Presentations. We mostly disregard this as the course needs to provide an alternative to this not-fully-accessible format anyways. What we can still improve is syncing timer states to student devices to inform then on the time left when use of this tool is such that it doesn't rely on the images in the slides, and hence can still participate and answer questions.

Auto-moving content is kept to bare minimum to begin with. Always has ability to hide or stop when looping or playing for more than a second.

We're fairly certain we don't have any situtions where this happens. This is user-uploaded content excluded, but though this would be nice, automating detection is too cost prohibitive for the forseable future

Apart from visual indication that focus is present (which is helpful), or extending a menu with available options for selection, elements don't change.

We consider the supplementing of (user uploaded) video with alteranative audio descriptions the responsibility of teachers/institutions. However we should support this teacher usecase better. Currently this can at best be achieved either by linking to an alternative version in the attached descriptions, or by adding an additional audiostream to the videofile (that contains this audio-description) before uploading, and communicating to disabled users that need this to download the video file and play it using a local mediaplayer that can switch between the available audiostreams.

Regular text is compliant. Only "disabled state" text currently doesn't comply, but with use of high-contrast browser addons it does comply. We're looking at adding an option in our accessibility settings that will make all text on light backgrounds (vast majority of text) meet contrast standards.

Due to our strict responsive design effort - practiced from start of development - this is supported everywhere with browser-based zooming

We've built an HTML based document viewer to display user uploaded content accessibly. Only very minor occurences remain (e.g. in our illustration work here and there)

Could be improved. We don't offer sitemaps for example. But we also consider this deficiency to be offset our predictable interaction design and in-app user onboarding/education. Important functions and page sections are also always mentioned in the skip-nav menu for discoverability.

Generally well visible with default browser outlines and highlights, but we haven't achieved mastery in this like e.g. Slack did, and still have some ambitions here because we consider this one of the most vital criteria

Language is indicated in HTML. Currently there are no language changes in our platform (except when done in user uploaded content). Requiring the uploader to specify the content language seems highly unlikely to succeed from an interaction design perspective (often neglected by user). Automated detection of the language of user uploaded content would be plausible. We consider this a future "nice-to-have" as usually in education the language variability of the content is already known by students.

Redesign of our input components with accessibility as a first principle has resolved outstanding issues. We haven't had a thorough checkup yet, but we're pretty confident there's little to no issues left.

Mostly not-applicable. Activity on our platform is potentially of high consequences of a student's study career. We carefully consider this during design and employ forgiving interaction patterns so likely already well covered. A thorough investigation would be needed to fully confirm this.

All our interface components that are activated by clicks/taps can be canceled by sliding of the component before up-event. We suspect a few undiscovered instances where this isn't the case might still be around.

Important actions are mostly all confirmed by live-reading the corresponding snackbar that they produce. Some (especially non-critical) actions are not yet.

Make sure your electronic publications have page numbers and those numbers match the printed version, if any.

If a dragging movement is required (e.g. when adjusting a slider), provide an alternative means of dragging such as tapping or clicking.

In our case this only pertains to the slider component, scrubbing in a video/document viewer, and swiping presentation slides. By now all have these have alternatives available.

Make sure all interactive targets (e.g., linked icons) take up at least 44×44 CSS pixels of space. This can include white space around the target.

Buttons have minimum size of 32x32px, plus 8px spacing around, which amounts to 40px, where the requirement is 44px (very close, 90%). However in most cases there's even better clearance and larger button sizes. Hence we estimate this at 95% compliance.

If you make a help option available, make sure it is available consistently, in the same relative place, so it can be located easily.

Contacting support and finding help is done through Intercom. This is consistently available and findable. However in our opinion discoverability can be improved. Improvement is planned for early 2021.

Any important controls (e.g., an edit button) should remain visible and/or available while that control is relevant and not stay hidden and/or disappear until they receive a mouseover or focus.

If there is a cognitive test to prove you are human (e.g., Captcha), there needs to be an alternative way to authenticate that does not require a cognitive test (e.g., 2-factor authentication).

When filling out a form, any previously entered information is available through autofill or selection. Confirming passwords and abandoned forms are exceptions.