Open Jermolene opened 3 years ago
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.
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.
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?
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?
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.
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.