inclusiveOCW - comments and feedback

Presentation mode (navigation) are not accessible by screen readers even in chrome

Presentation mode: no cursor interaction in slides possible (to read out line by line). However there the form-field are in a clickable mode

High

This issue is caused by the need to have role=application within the presentation mode to allow all users to use keyboard shortcuts to control the presentation. This is a know issue with presentation slideshow tools (see

https://github.com/shower/shower/issues/220 for discussion of the same issue on an open source presentation library). Currently a screen reader user who was presenting with SlideWiki can use left/right or spacebar to move through the slides and will hear a summary of each slide when it loads.

We are adding a region to wrap each slide and this will be labelled with the slide title which may help navigation. Although not always consistent we have found the following behaviour with JAWS and IE/Firefox:

• on change of slide text content and slide notes are read aloud
• using spacebar to change to the next slide. Focus goes to next slide button. Use tab to move focus to the slide number. Then H (JAWs command) which should take focus to the top of the slide and allow use of arrow keys to move through the slide content.

We are also looking into whether we can adapt the overview mode to provide a view without the application role which would show all the slides.

The need to use the URLs to navigate to a specific slide

Medium

Zoom in and out does not work as intended. If the slide is full with text and image, when zooming in the navigation buttons are enlarged while the slide content are still the same size.

(https://slidewiki.org/presentation/109716-2/projekt-inclusiveocw/109716-2/714602-19/#/slide-714602-19)

High

Ease of use with ZoomText 11

Navigation with arrow keys work. Generally, the focus to move to the next slide, changed i.e. the focus is on the arrow keys he remains there and users at large magnification not detect whether the change has taken place (certainly a common scenario, if the slides) be read from top to bottom)

Proposal: place the focus on the top of the slides change on next slide[AJ7]

Is it possible to have a footer and numbering for the slides?

Medium

Proposal: In the presentation view, adjustable much like in PowerPoint
Offer audio play function, e.g. useful for use at trade fairs

SWIK-2486 - Getting issue details... STATUS

Why decks and slides appear in the search results colourful mix? [AJ1]
Proposal:
- in search results automatically set the chronological view
(new first)[AJ2]
- Subselect offer: decks / slides
- Thematic selection offer, search in categories enabling

Currently working on improving search results.

When we add subject categories to decks, you will be able to filter the search results by category and education level.

WCAG-Success Criterion 2.4.7 Focus Visible. Any keyboard operable user interface has a mode of operation where the keyboard focus indicator must be visible.

For example, put a red pointed frame around the focus

20181122 Das Problem besteht weiterhin, z.B. auf der Startseite ist der Tastaturfokus nur schwer oder gar nicht erkennbar. Getestet mit Chrome und FF

The problem persists, e.g. on the start page, the keyboard focus is difficult or impossible to recognize. Tested with Chrome and FF

SWIK-2494 - Getting issue details... STATUS

SWIK-2606 - Getting issue details... STATUS

WCAG-Success Criterion 2.1.1 Keyboard. All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.
Page-specified shortcut keys and accesskeys (accesskey should typically be avoided) do not conflict with existing browser and screen reader shortcuts.

Page: https://slidewiki.org/ (Build c85e59f@r2.8.x-VMU-EKDDA)
The language selection is not keyboard-operable. The language selection requires an implementation for example, as a combobox according to the ARIA authoring practices. The pause switch of the slideshow can not be activated with the keyboard. Also, the focus is not visible. The back / forth switches cannot even be focused

Page: https://slidewiki.org/deck/108227-1/einfuhrung-in-die-kommasetzung/slide/706745-1 (Build c85e59f@r2.8.x-VMU-EKDDA)
The tabs below the slide are not triggerable with the keyboard, because the <a> element has no href attribute.
The "Contributors" pop-up switch in the Creator area of the sidebar is not operable/usable with a keyboard.

Update: Build acd24a6@ - WCAG 2.1.1

https://slidewiki.org/

"Sign in" ist nicht mit der Tastatur erreichbar, sondern nur mit der Maus

Lösung: als richtigen Link a mit href anlegen

https://slidewiki.org/deck/118196-1/slidewiki:-towards-a-collaborative-and-accessible-platform-for-slide-presentations?language=en

"Activity Feed" ist tastaturbedienbar, obwohl es kein interaktives Element sondern eine Überschrift darstellt.

<h5 class="ui small header" tabindex="0">Activity Feed</h5>

Lösung: tabindex= "0" entfernen

https://slidewiki.org/search?keywords=inclusiveocw&sort=score

"Advanced Options" Ausklappmenü ist nicht tastaturbedienbar

Der Rahmen der einzelnen Einträge ist fokussierbar, jedoch ohne Aktion, dieser kann aus der Fokusreihenfolge entfernt werden.

Lösung: tabindex="0" entfernen

SWIK-2329 - Getting issue details... STATUS

SWIK-1091 - Getting issue details... STATUS

SWIK-1994 - Getting issue details... STATUS

WCAG-Success Criterion 2.1.2 No Keyboard Trap. If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tabkeys or other standard exit methods, the user is advised of the method for moving focus away.

Page: https://slidewiki.org/ (Build c85e59f@r2.8.x-VMU-EKDDA)
Keyboard trap in the FF: button "Erstelle Präsentation | Create a presentation!" there is a keyboard trap, the user cannot navigate further on the page and jumps back and forth within the blue field and the button.

SWIK-1951 - Getting issue details... STATUS

SWIK-406 - Getting issue details... STATUS

WCAG-Success Criterion 2.4.4 Link Purpose (In Context). The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.
For good meaning, alternative text should be in the same language as the page language.

Page: https://slidewiki.org/ (Build c85e59f@r2.8.x-VMU-EKDDA)
For example: search field, "see all"-Button

Page: https://slidewiki.org/deck/108227-1/einfuhrung-in-die-kommasetzung/slide/706745-1 (Build c85e59f@r2.8.x-VMU-EKDDA)
For example Open slideshow in a new tab, Fork deck, Zoom, navigation for presentation

So far only language for entire presentation possible, single words or blocks of text in another language are not taken into account and thus incorrectly read.

Proposal: Embed the language choice for individual slides and text within slides (text box level)[AJ3]

We will be adding language tags at the slide level as part of our translation feature.

Heading 1 should be applied to the link to the SlideWiki homepage (on the SlideWiki logo). This is a bug and will be fixed

The heading structure is designed that the deck title is Heading 2 and the slide title is Heading 3.

We can add aria labels (hidden from the UI) to add a description to these headings.

The structure of lower headings needs to be improved over the next sprint.

Proposal: Jump-to links work "Slideinformationen", for "Start presentation" for "Edit slide", E.g. that would be helpful also a shortcut key to start Presentation, this makes the operation faster in comparison to the use of the form field list "insert + F5"

Abi: We can look at adding an access key but we need to make sure they do not interfere with screen readers if you have suggestions for:
- Start presentation
- Edit slide
- Next slide
- Previous slide

Would it also be helpful to have a shortcut key to jump to the slide content?

BFW: We looked for easy to handle access keys and found the following,
please add these access keys:
‐ Start presentation: Alt + s
‐ Edit slide: Alt + w (w stands for “write”)
‐ Next slide: Alt + n
‐ Previous slide: Alt + p
It works with JAWS and NVDA + IE 11/Firefox/Chrome, as well as with iPad and Macbook.

At the moment, when you change slides in the presentation mode, the text content is automatically read aloud but this does not include alt text describing the graphics.

It is possible to navigate through the slide content and read it all if you can get focus into the slide. We did force focus to be on the content of the slide items but we had negative feedback from non-screen reader users as the focus indicator was always visible.

Abi: I want to work through this again with the developer to see if we could have something like a shortcut key to focus on the title.

BFW: Another shortcut key would be a stopgap. You should be able to read the content of a slide easily.
Maybe it is possible to have “Alt + n” (see above) linked with the focus on top of the next slide. 

This also would help users of Zoom Text 11. Pressing the next slide button would bring the focus on top of the slight and the user can see this (currently he can’t recognize the change of the slide as the focus remains on the two arrows).

We are also aware that in imported slide the reading order is often incorrect (as they are wrong in the imported slides). We are looking at whether we can force the title to the slide to be automatically at the top of the reading order.

The right arrow or left arrow keys used by JAWS to read character by character. Thus, the call to the next slide is only possible if this button is passed through before JAWS key 3.

Proposal: E.g. alt + n for "next slide" and ALT + p for "previous slide" set.[AJ3]

Abi: Would you like an announcement on the next slide button that there are no more slides available? Or would you prefer to have a final slide for example with a link returning to SlideWiki?

BFW: An announcement “Next slide not available” would be ok.

Proposal:
-Automatic detection of language maintain (see for example online
Dictionaries - JAWS voice output accordingly reads)

We are just about to add translation options into the platform.

We will look to set the language tag at a slide level which would tell JAWs what language to use.

Abi: Please, could you provide the provide the slide examples for these issues? YouTube videos may be embedded within the slide so ALT + arrow left would take you back to the previous slide.

BFW: Videos on Youtube: Alt + arrow left / Alt + arrow right gets the user to the previous/next slide = OK

Kontrast der markierten Stellen muss auf 4,5:1 erhöht werden

Kontrast der markierten Stellen muss auf 4,5:1 erhöht werden

SWIK-2049 - Getting issue details... STATUS

Checked colour contrast requirements in WCAG and links are sufficent as there is contrast with black text.

Headings Page: https://slidewiki.org/ (Build c85e59f@r2.8.x-VMU-EKDDA)
<h2>-<h4> hierarchy is not clear. "Welcome to SlideWiki | Willkommen bei SlideWiki" should be marked as <h2> not <h3>. "Erstelle eine Präsentation | Create a presentation" is subordinate to the point and should therefore be <h3> sidebar
"Beginnen | Begin" and "Hervorgehobene Präsentationen | Highlighted Presentations" are content-related areas, so they should be marked as <h2> not <h3>

Update: Build acd24a6@ - WCAG 1.3.1

https://slidewiki.org/

<h1>+<h2> ("Willkommen bei SlideWiki" + "Learn more about SlideWiki") sind versteckt, jedoch für den Screenreader zugänglich. Könnten Diese beiden Überschriften für alle zugänglich gemacht werden?

"Open educational resources for all learning environments" + "SlideWiki: Create, Share and Enjoy Presentations" beides als <h2> ausgezeichnet unterscheiden sich optisch jedoch stark voneinander

<h3> "Featured deck" ist optisch der <h2> "Vorlesungsreihe Informationssysteme" übergeordnet, vielleicht sollte "Vorlesungsreihe Informationssysteme" nur als Link und nicht als Überschrift ausgezeichnet werden.

https://slidewiki.org/about

"With SlideWiki you can:" + "Features coming soon:" = <h3> besser als <h2> auszeichnen, es gibt keinen Grund hier eine Überschriftenebene zu überspringen

https://slidewiki.org/contactus

"Kontaktanfrage" = <h2>, "Rückmeldung" = <h3> besser wäre beides eine Ebene anzuheben und auf der Seite mit <h1> zu starten.

WCAG-Success Criterion 2.4.1 Bypass Blocks. A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

For example, it is possible to insert jump links at the top of the page to facilitate navigation on the page (navigation, presentation, deck information, footer ...)

WCAG-Success Criterion 2.4.2 Page Titled. Web pages have titles that describe topic or purpose.

Page: https://slidewiki.org/ (Build c85e59f@r2.8.x-VMU-EKDDA)
„Authoring platform for OpenCourseWare“ is not meaningful, since English-speaking on a German-speaking website

Page: https://slidewiki.org/deck/108227-1/einfuhrung-in-die-kommasetzung/slide/706745-1 (Build c85e59f@r2.8.x-VMU-EKDDA)
Presentation mode: all slides have the same page header. For describing, slide heading + slide number (eg: 2/40) should be added.

WCAG-Success Criterion 2.2.2 Pause, Stop, Hide. For moving, blinking, scrolling, or auto-updating information, all of the following are true. Moving, blinking, scrolling: For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; Auto-updating: For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.

The Feedback form success message, that is shown after submitting the form, closes automatically after 5 seconds.

WCAG-Success Criterion 1.3.1 Info and Relationships. Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. Using standard text formatting conventions for paragraphs.

Page: https://slidewiki.org/ (Build c85e59f@r2.8.x-VMU-EKDDA)
For example: "Erzeuge Folien in unserem Editor ...“, „Verwende den Slideshow mode“ ...

Using ol, ul and dl for lists or groups of links.
Page: https://slidewiki.org/deck/108227-1/einfuhrung-in-die-kommasetzung/slide/706745-1 (Build c85e59f@r2.8.x-VMU-EKDDA)
Table of content should be marked as a list. Also, the footer could be marked as a list.

Update: Build acd24a6@ - WCAG 1.3.1

https://slidewiki.org/imprint

Hervorhebnungen "Provided as-is:", " Licensing:" sind mit <b> ausgezeichnet

Lösung: statt <b> <strong> oder <em> verwenden

Update: Build acd24a6@ - WCAG 1.1.1

https://slidewiki.org/

verlinktes Vorschaubild hat keinen Aussagekräftigen Alternativtext (Feature image)

Besser wäre es die Verlinkung zu entfernen, da der Link reduntant zum nebenstehenden Link (Vorlesereihe Informationssysteme) ist. Man kann das Bild auch als dekorative Grafik unverlinkt mit einem leeren alt-Attribut auf der Seite einbinden und aus der Fokusreihenfolge entfernen.

Question: there are corresponding versioning for the public version
Numbers?

Proposal: Version number release, that facilitates the systematic
Testing also in regard to the pending tests on BITV and WCAG conformance (DZB)

There is an SVG-image in the same Link-element that also holds the username (of the creator) in the Creator field. The image should be hidden to a screenreader with aria-hidden=”true”.

• On top of the slide navigation panel (for the screen reader at the beginning of the page) there is the name of the presentation as a link to the page the user is already on, which is at the same time declared a heading. Semantically this doesn’t constitute a heading but seems more like breadcrumbs with only one element. Thus the heading declaration should be removed. Instead there should be a hidden or visible text saying something like “You are here:”.

The current slide number in the lower right is read by the screenreader just as a number. It doesn’t become clear that this number indicates the number of the currently shown slide. An informative text should be added, i.e. sitting outside of the visible area of the page, that says something like “current slide:” or the attribute aria-current=”page” should be added to the element.

“Search…” in the searchfield without focus has 1.3:1, with focus 1.9:1. It should be at least 4.5:1 for the better (w/ focus), 3:1 for the worse (w/o focus).

For the search field the placeholder text is not sufficient for a screenreader. The accompanying label element is hidden for all users with the hidden-attribute. This hidden-attribute should be removed.

Placeholder text contrast

Search field needs label

• grey (inactive) buttons in the bar below the preview images should not be focusable and thus should include the attribute disabled. This would convey the inactive state correctly to the screenreader.

• The navigation menu is not usable via keyboard because only list  <span>-Elements have been used, that are not usable via keyboard. Instead <button> or <a href>-Elements should be used.
• 

The main content, declared with <main> currently includes only the slides area. In any case the button bar below the slide area should be included in <main>. The area below (Sources, Tags ..) is not included in any page area. It should either be included in the <main> too or should be included in another page area (i.e. role=”complementary”). In the later case the heading level should be set so that it is on the same level as the other columns (Select language, Creator etc..)

Focus-Order after closing a modal dialog

Presentation view: The Navigation-menu is a modal dialog because the rest of the page is dimmed when the menu is called. The Focus thus should also only move inside this menu.

Name, Role, Value of interaction elements

• Language selector has attribute role=”listbox”. This attribute should be on the actual list-element (<div class=“menu transition visible“>). Also the list of languages should be made usable via keyboard, see the following example: https://www.w3.org/TR/wai-aria-practices-1.1/examples/listbox/listbox-collapsible.html
• Advanced search: The dropdowns “Search Field”, “entity” etc. are realized as <select>-element and as a separate group of <div>-elements. The <select> however ist made invisible with display:none for all users and the <div>-group is not conveying the currently selected state to the screenreader because the declaration as a combobox/switch with list-popup and the display of the current element inside the dropdown with aria-activedescendant are missing. All dropDown-fields can e realized like this.
• Advanced search: The select fields “Users” and “Tags” are not realized as accessible Tokeninput-fields. An option would be to use a <select> with multiple selection enabled. If the visual appearance should stay as before then the parent element had to be realized as a list <ul> that holds the already selected values, the delete switches and, as the last item, an <input>. Find a relatively good example at: http://instructure-react.github.io/react-tokeninput/
• Presentation overview: For a screenreader it doesn’t become clear that the Tabs below the slide area (Sources, Tags, etc.) are actually tabs. The Tab-Links are also not triggered by keyboard. A tabindex-attribute should be added as well as a keyUp-Event, which behaves like a click-Event but only for the space and enter-key. See the following example: https://www.w3.org/TR/wai-aria-practices-1.1/examples/tabs/tabs-1/tabs.html