Further improvements to screenreader experience

[Jermolene]

This thread takes over from earlier feedback in #650, with this post being copied from a comment by @Flameborn:

I am currently testing e84c87e built via the build-site.sh script under Safari, via VoiceOver. Most of the issues I found, however, will be generally present when using other screen readers as well, such as NVDA, Jaws, Narrator, Orca, etc.

1. Controls that cause sections to appear, e.g. the More, or the tag list button need an aria-expanded attribute, which is true when the section is shown, and becomes false when the section is hidden.
2. It seems like the tags are automatically shown by default, or when the Tag field is focused. While this is great visually, a screen reader user needs to click the tag list button afterwards, since there is no way to skip past the list of tags quickly. When the tag field loses focus, the list of tags should be hidden, so that showing/hiding tags is only controlled by either focusing the field, which allows clicking on a tag visually, or via the tag list button, where the list of tags can be navigated to.
3. The available tags do not seem to have a control type defined. Without looking at the source, I am guessing that they are a list of div or span containers. Screen readers only announce that these tags are clickable, but they can't be focused via the tab key, nor they are conveyed as a button (which essentially they are). Adding a role ARIA attribute defined as a button, as well as setting the tabIndex attribute to -1 should make these items focusable via the keyboard as well.
4. I am not sure how customizable the default TiddlyWiki editor is, in case it is: The editor toolbar widgets should be contained in an ARIA Toolbar, so that screen readers can display these controls as part of a single group. Under MacOS, this allows skipping past all the toolbar items, as opposed to having to navigate through every single widget to reach the edit textbox.
5. It's worth noting that the More Actions button of the editor needs an aria-expanded attribute as well.
6. The content type and the field list behaves the same way as the list of tags, see above.
7. Items in a group that can be selected to display their content, such as in the case of the control panel buttons, aria-current should be used. In this case, you could add a tab role for the button, or even use aria-selected, so that a screen reader user knows immediately which page is active, rather than having to deduct it from the content.
8. The button for expanding a keyboard shortcut (Control Panel -> Keyboard Shortcuts) does not have a text label. The same is also true for defining a new shortcut, which I assume is a new/edit button for the various platforms.

[Jermolene]

Thanks @Flameborn much appreciated.

I've just pushed d56e8764a1f02a214df5da1cc95191be2da2491b that addresses (1) and (5), it should be available to test at https://tiddlywiki.com/prerelease in 5 minutes or so.

[Flameborn]

First of all, I really appreciate the time and effort put into addressing these issues. Making a non-linear wiki accessible while making it not confusing is quite challenging, since screen readers by nature are linear.

The expanded attribute looks good, thank you very much. A lot of things make more sense now, knowing which control would open up a list of further controls, if that makes sense.

I'm going to edit this comment, if something else comes up, so things won't get chaotic.

A few things:

The More and Tools buttons on the sidebar need similar treatment ☺️

The Info button when you hit More does not need an aria-expanded attribute, since you are not toggling it, it acts more like a link in this case.

I forgot to mention that it would be really nice if we could have labelled regions, for example one for the sidebar, one for each tiddler, etc. This is mainly to aid quicker navigation, similarly to how tiddler titles have a heading, as well as to convey what belongs to one group. Since a tiddler technically begins before its title, (i.e. there are controls before it), these regions could indicate where the tiddler begins and ends.

For a start, labelling the sidebar and tiddlers should be enough, but some others might pop up as well later on, I just haven't used TiddlyWiki for long enough to see what might be confusing for someone not being familiar with a non-linear wiki.

ARIA has some pre-defined regions, but in this case I think we should use named regions. They are described here, but the TLDR is that they can be created by tagging a div element with an ARIA role of region, and using labelledBy if a visual label is available (e.g. the tiddler tittle), or an ARIA label if there is no visual label, e.g. in the case of the sidebar.

Thank you very much again for addressing these.

[kaiyasa]

Many years ago, I used Tiddly but dropped from using it some time ago due to my failing vision. I started looking at it again and see it has improved from an accessibility respect.

I see this is nearly a year old and I think I can help from a user’s perspective.

I’ve started my testing on Windows 10, Chrome/Firefox/Edge and NVDA. I do plan trying with Linux/Orca and MacOS/VoiceOver since I am using all three platforms.

Starting from the sample blank.html…. The first issue is the SR enters input mode on and “edit”. With no context as to what I am editing for. Leaving input mode and probing around what appears to be a flattened list of an edit field and advanced search button. Preceding that is another flattened list of labeled buttons.

There is a hide sidebar button but no sign of a sidebar. Activating “open control panel” gives no audible clue something has happened and probing around the area only hints at a DOM change somewhere since the SR does a little tab eating on the first probing.

I can go on further but the key issue here is the lack of accessible structural elements beyond the most basic headings, links , lists, and form input controls. I believe these concerns can be addressed and start on the UX part of useable accessibility.

Any interest? Many years ago, I used Tiddly but dropped from using it some time ago due to my failing vision. I started looking at it again and see it has improved from an accessibility respect.

I see this is nearly a year old and I think I can help from a user’s perspective.

I’ve started my testing on Windows 10, Chrome/Firefox/Edge and NVDA. I do plan trying with Linux/Orca and MacOS/VoiceOver since I am using all three platforms.

Starting from the sample blank.html…. The first issue is the SR enters input mode on and “edit”. With no context as to what I am editing for. Leaving input mode and probing around what appears to be a flattened list of an edit field and advanced search button. Preceding that is another flattened list of labeled buttons.

There is a hide sidebar button but no sign of a sidebar. Activating “open control panel” gives no audible clue something has happened and probing around the area only hints at a DOM change somewhere since the SR does a little tab eating on the first probing.

I can go on further but the key issue here is the lack of accessible structural elements beyond the most basic headings, links , lists, and form input controls. I believe these concerns can be addressed and start on the UX part of useable accessibility.

Any interest? Many years ago, I used Tiddly but dropped from using it some time ago due to my failing vision. I started looking at it again and see it has improved from an accessibility respect.

I see this is nearly a year old and I think I can help from a user’s perspective.

I’ve started my testing on Windows 10, Chrome/Firefox/Edge and NVDA. I do plan trying with Linux/Orca and MacOS/VoiceOver since I am using all three platforms.

Starting from the sample blank.html…. The first issue is the SR enters input mode on and “edit”. With no context as to what I am editing for. Leaving input mode and probing around what appears to be a flattened list of an edit field and advanced search button. Preceding that is another flattened list of labeled buttons.

There is a hide sidebar button but no sign of a sidebar. Activating “open control panel” gives no audible clue something has happened and probing around the area only hints at a DOM change somewhere since the SR does a little tab eating on the first probing.

I can go on further but the key issue here is the lack of accessible structural elements beyond the most basic headings, links , lists, and form input controls. I believe these concerns can be addressed and start on the UX part of useable accessibility.

Any interest?

[Jermolene]

Thanks you @kaiyasa, that's very helpful.

With your and @Flameborn's comments it's clear that there's a lot of work to do.

In a case like clicking the "open control panel" button, what would be the preferred way to indicate the relationship between the button and the newly appearing DOM elements?

You mentioned "flattened lists" with respect to the toolbar buttons – would it make things easier if the toolbars were implementedas HTML <ol> elements?

Do you think introducing named regions would be a good next step?

[kaiyasa]

It’s going to take a bit to address each UI “feature” and it related behaviors to answer more concretely. However, my reference is to a behavior which happens to lists that have been CSS’ed to display horizontally without bullets or such. A screen reader has a habit of reading things in a line oriented way and these lists usually fall into the treatment. So, I find that list and get a slew of list elements read to me all at once. Hence I coined them as “flattened” lists because visually and structurally they appear as a single line of text in the accessible object models.

Now, the control panel example. I’m having some trouble understanding the conceptual changes desired. It seems to act as a toggle to brin a few buttons onto the page and make visible a system tiddle. So, it’s making two changes that appears to serve different purposes. Barring an examination of the feature itself. My first thought it is a toggle or checkbox role semantics and this needs to be expressed accessibly.

Next, the screen reader needs a clue that a “focus” change is desired (maybe to the newly opened tiddle?).

Since I believe, the control panel isn’t a hot spot of user interaction. I would feel a focus on basic structural markup and quick navigation would be an awesome enhancement. This Segway’s into your questions about the value of named regions. As an advanced screen reader user, I always appreciate well done regions. TiddleWiki could definitely use a few. I can see potential for four so far but for the average screen reader user, these are mysterious and misunderstood. Thus, a site design can’t rely solely on them.

In my further exploration of the wiki system, I found the new tiddle creation generally usable until I hit the type field. I’ll write on this topic later since it’s like 1/3 of the main function of the system and huge number of user experiences here. My next task was to retrieve the tiddle after a save and close of the wiki. I found this very frustrating to do. And finally, I was hoping some kind of “tiddle” index would be obvious but no luck so far. And, I need to relearn the tiddle system again.

Still, I think there is amazing potential for a blind user once the visual elements have a “structural” mark up basis for the accessibility object model to form. Secondly, I feel sighted users would benefit from some thoughtful shortcut keys added to speed up creation, editing and surfing the wiki.