If you try to download a certain deck of slides from the course material in pdf format, the server throws an error.

Inconsistency w.r.t. the Markdown editor new lines reported via email:

When writing text into the Markdown Editor and pressing Enter:

Enter once: The text in the slide is still displayed in one line.
Enter twice: Text in the slide is displayed in a line below but with a big space.

Compared to the regular editor:
Enter once: Text in a line below with a small space
Enter twice: Text in a line below with a big space

I think it should be good to have the Markdown working the same way as the regular editor.

Reported by Petra

Text editing buttons in the "Speaker note" area can not be reached with the keyboard (https://slidewiki.org/deck/127411/_/slide/836159-2/836159-2:1/edit?language=de).

The nesting of the hierarchy levels does not correspond to the content structure on both sides checked. There is twice a heading that refers to personal settings ("Persönliche Einstellungen" and "Profile Settings").

A heading h1 should be created that precedes the following heading levels (suggestion: "Eigenes Profil"). The headings "Persönliche Einstellungen", "Gruppen", "Analytics", "Bild austauschen" and "Ändere meine persönlichen Daten" should be assigned to level h2.

https://slidewiki.org/user/vivien.zschammer/settings/profile
https://slidewiki.org/user/vivien.zschammer/stats

If you look at the image metadata in the store on this presentation, you'll see that US-style quote marks (") were saved in the underlying database, instead of html & code &quot. That was achieved by entering the " symbol into the "caption" form while creating the figure. This means that alt text cannot contain quotes entered as such.

When importing an existing slide deck while adding a new slide deck, the import sometimes hangs at 65%

(reported by Gábor)

Security risks were found for the following packages from package.json:

• diff
• webpack-dev-server

Page: https://slidewiki.org/addDeck

If nothing has been entered in the form fields marked with *, the error message appears after the form fields. The message is therefore difficult to find and it is also not linked to the form field.

If the message can only appear after the form, at least the attribute aria-describedby must be inserted on the respective form field and refer to the id attribute of the error message. Alternatively or additionally, it would be good to put the error message in front of the form.

All form fields are reachable via tab-key, but there is no optical keyboard focus on the form fields "Wählen Sie das Thema" und "Wählen Sie die Tags".

https://slidewiki.org/addDeck

Hi there,

My team is developing a course on the SW. We will use a mailing service to enroll students.
That's the pipeline:

1. we write them
2. They will subscribe a custom form outside SW that will ask them to register on Slidewiki.org.
3. they register themselves on SW

So at that point we would need a process of reconciliation of subscribers between our mailing system and the subscribtions on SW. It is possibile to have any automated notification ​when a student will register on slidewiki?

We need something like: send an e-mail to THIS Team for each user that will fill a special field on SW form when registering.

Thank you

When trying to edit a slide, none of those buttons are reachable via keyboard (https://slidewiki.org/deck/127411/_/slide/836159-1/836159-1:1/edit).

When the 'save' button is clicked an API request is performed which returns a 500 error.
The response body holds the following JSON:

{"message":"Cannot read property 'length' of undefined"}

On the Deck overview page there is no indication for a screen reader user where the start of the page tree (on the left) is:
A user with a screen reader can navigate the slide tree without problem. The start of the slide tree, however, is not marked by anything that a screen reader will read. At the moment this is only visually indicated.

A quick for this would be to put a caption above the slide tree.

Another option could be to add a label element that is not visible but still read by a screen reader (added by bwulff in complete absence of knowledge about accessibility engineering on the web, so careful about this one!)

A lot of text is still hard-coded in the system. Additionally, not all translation strings are translated.

When a user is logged into Slidewiki and closes the browser without logging out of Slidewiki before, the next time SlideWiki is used, the editor and other features are not working anymore.

This can be resolved by completely resetting the browser.

Reported for Chrome 75 on Windows.

Following sites have a wrong headline structure:

1. The Add-Deck-site (https://slidewiki.org/addDeck) doen´t have a consistent headline structure. The headings h1 and h2 are missing. "Füge eine Präsentation zu SlideWiki hinzu" should be h1.

2. The My-Presentation-site (https://slidewiki.org/user/vivien.zschammer) doen´t have a consistent headline structure.

4. https://slidewiki.org/deck/127411/test/slide/836159-1/
5. https://slidewiki.org/deck/127411/_/slide/836159-1/836159-1:1/edit

The following access keys should be integrated in the slide view:

• 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 (tested in July 2018).

Issue coming from iOCW Google Group

Work has been done already on making SlideWiki responsive. But some extra work is needed to ensure that all pages are responsive and rendered correctly. I think it makes sense to first list all pages/components that don't work well on small screens and afterwards fix them.

Additionally, the mobile version should be tested with mobile screen readers (for example Talkback on Android and VoiceOver on iOS).

This work is part of WP5 (T5.2) in the iOCW task description.

@rezatavakoli is working on detecting issues w.r.t. responsiveness.

reveal.js supports the fragment class for initially hiding elements on a slide and then making them visible step by step. See: https://revealjs.com/#/fragments

This could be a nice enhancement if we expose the feature in the editor since it would enable users to produce more dynamic and structured presentations while not changing the markup significantly which means that it wouldn't affect any content analysis.

Enhancement was proposed by a user via feedback form.

Pages 8 and 9 of the presentation contain quotes that are not marked as such.

The creator of the presentation should be given the opportunity to label quotes as such so that they are marked with the element blockquote in the presentation view.

https://slidewiki.org/presentation/81127-1/overview-of-accessibility/81127-1/437649-3/?language=en-/slide-719796-3

Request: The intent of this Success Criterion is to make information conveyed by non-text content accessible through the use of a text alternative. Text alternatives are a primary way for making information accessible because they can be rendered through any sensory modality (for example, visual, auditory or tactile) to match the needs of the user.

Issue:

1. https://slidewiki.org/presentation/81127-1/overview-of-accessibility/81127-1/437649-3/?language=en-/slide-719796-3

• The menu button doesn´t have an alternative text.
  --> An alt-text should be provided by aria-label or title.

Support dragging an image into the Markdown editor to upload the image.

Requested by Petra

The version number is not displayed on the landing page.

The version number should be displayed on the landing page in the footer. On the right hand side, where already the build commit is displayed.

Requirement: Automate the update of the version number in the code by extending the /make_version.sh script that puts the build commit in the footer during Docker build!

NodeJS was recently published as version 5.6.0 (Changelog). Make sure to upgrade NodeJS on your local system and to add 'engines' object to packages.json (like in this showcase: package.json):

"engines": {
    "node": "5.6.x"
}

This will assure that we will develop with all the latest features and fixes.

Although the text field below the slide title can be focussed with the keyboard, no entries in this area are possible. Text can only be added in the title area (Editing a slide: https://slidewiki.org/deck/127411/_/slide/836159-1/836159-1:1/edit?language=de).

from where the slide are picking up the data for display.
some api request is being made but i am unable to trace it.

in app.js i found this but not sure what it is

// register plugins
app.plug(fetchrPlugin({
xhrPath: '/api' // Path for XHR to be served from
}));

When using SlideWiki with JAWS, the two input fields for the search are read (captioned) as follows (when German is the browser language/UI langauge):

Chrome 76:

1. Nicht bezeichnet Eingabefeld
2. Willkommen bei SlideWiki Eingabefeld

Firefox 52:

1. Search Eingabefeld
2. Search for decks or people

So there are different captions read in different browsers, this should be consistent.

Also note: The English version is more consistent. So the inconsistency in German is most likely rooted in the internationalization.

There is additional information available on how to this should be approached (get it from Ben)

This concerns especially the following pages:

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

https://slidewiki.org/deck/108346-1/_/deck/108346-1

• titles should be in the language of the page: maybe name them "Titel - allgemeine Information | SlideWiki" bzw. "Titel - Präsentationsübersicht | SlideWiki"

For creating slide questions, it is currently only possible to add four questions (see screenshot). It should be possible to add more questions dynamic (e.g. an plus icon button that adds another row).

Loading indicators are missing for at least the history and usage tabs.

When a slide contains images, the height of the slide can be set incorrectly. This because the images are loaded asynchronously. Make sure that the slide height is adjust on a full page load (temporary fix would be to make the slide content scrollable, so at least it is possible to see the slide content).

Example:

I'm trying to upload a new deck and after I select it from my files the upload button is disabled as shown below in the image, thus not allowing me to upload it.
I'm not sure if it's a bug or the expected behavior because of some permissions I don't have or something similar.

I'm running the platform locally and using all the services from the experimental server.
I'm at this commit: 1dcab75.
Using Google Chrome version 64.0.3282.119 (Official Build) (64-bit)
Ubuntu 17.10

In the console I see this message when I select the file:

Example: https://slidewiki.org/presentation/126504-1/ausbildung-am-bfw-halle/126504-1/?language=de#/slide-843277-9

Problem: JAWS is reading that an element is clickable, while it's not.

Solution: remove the tabindex when an element is not interactive

While traversing through slides, the error shown in the figure appeared. Although the slide navigator to switch back and forth worked perfectly but presentation view of the slide was unable to load the new slides.

An error occurs when updating the display name in the account settings

Headings that semantically belong to levels h1 and h2 are marked as levels h3 and h4.

https://slidewiki.org/presentation/81127-1/overview-of-accessibility/81127-1/437649-3/?language=en-/slide-719796-3

Request: Paragraphs are marked with suitable structural elements. The division into smaller units facilitates handling and understanding.

Issues:
Some elements of different pages are not marked with the necessary p-element:

1. https://slidewiki.org/

• "Fangen Sie sofort an. Meine Präsentationen." (missing p)

2. https://slidewiki.org/presentation/81127-1/overview-of-accessibility/81127-1/437649-3/?language=en-/slide-719796-3#/slide-437649-3

• Empty p-elements should be removed.
• List elements should not be additionally marked with the p element.

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

• text area below "Results" (missing p)

4. https://slidewiki.org/accessibility

• paragraphs within the boxes (missing p)

• the menu in the presentation view (reveal.js) ist in parts not usable at all with a screen reader
• the menu seems to have little use at all since the user can go back to the slidewiki view in order to browse the deck structure

--> proposal: remove the menu from the presentation view

By hiding the user image for screen readers, blind users lose information. At the same time, it makes it difficult for them to upload or check their own profile picture. The graphic should not be hidden by aria-hidden and should contain a placeholder text if the user image is not available. Otherwise it should contain an alternative text that describes the person depicted.

https://slidewiki.org/user/vivien.zschammer/settings/profile

"Speaker notes" is marked with the element b. Strong or em should be used instead of b.

https://slidewiki.org/deck/127411/_/slide/836159-2/836159-2:1/edit

to reproduce:

1. open any presentation, e.g. https://slidewiki.org/deck/584-4
2. click the download button => as expected, the format list pop-up
3. click somewhere else on the page to close the format list and abort the download => unexpectedly, "... downloaded this deck 0 seconds ago" appears in the "Activity Feed" on the right

Expected: "...downloaded..." appears after starting the download, or maybe even only after it successfully completes.

This behaviour seems to be client-side-only or there is some server-side clean-up, because after refreshing the page, this activity item is gone.

Currently in SlideWiki different types of dropdowns (or select) components are used. E.g. Semantic UI JQuery, Semantic UI React, native browser select and custom made dropdown elements. This results in inconsistent behavior of those components. Additionally, it is hard to maintain these different components (i.e. making them accessible etc.).

I'm trying to replace all dropdowns by the Semantic UI React component. This component automatically adds (most) aria-* attributes. I replace this at several pages now, but I need someone to test the accessibility thoroughly before I continue to replace this everywhere. In case some of these dropdowns are not accessible, I will fork Semantic UI React, and implement this myself (afterwards merge it back into Semantic UI React).

I started this work in the branch: Consistent-dropdowns. The following dropdowns have been replaced:

• Personal settings: User Interface Language (regular dropdown)
• Personal settings: Country (searchable dropdown)
• Deck settings: Choose deck theme (regular dropdown)
• Deck settings: Education Level (regular dropdown)
• Deck settings: Add users for edit rights (async searchable dropdown without selection)

@VivienDZB Do you have a local version of SlideWiki running? If so, can you check out the branch locally and test if the replaced dropdowns are fully compliant to the accessibility standards? Thanks!