How to improve TiddlyWiki for users with assistive technology

#1

Without wishing to derail this very interesting thread, just jumping in to say that we are committed to improving the TiddlyWiki experience for users of assistive technology and so welcome feedback or suggestions. TiddlyWiki strives to be a universal solution for everybody.

4 Likes
TiddlyWiki as a modelling tool - let's discuss
#2

Yes, TW is accessible well, and is usefull for blind people too. In next weeks we create czech TW microsite for describing their big functions and benefits for czech users, many thanks.

Unfortunatelly, accessibility of some plugins from developers isnt so ideal, for example unlabelled buttons, etc.

BUT ONE THING: In TW all images are not labelled (in UI, in toolbars if they are only as images, in tiddlers, etc). Yes, I know that primary it is problem of content creator, but working with images (in UI too) is little bit frustrating :slight_smile:

1 Like
#3

Can I suggest a new thread on accessibility and example code and guidelines be given so people can improve the flexibility of their solutions.

#4

Thanks for your feedback. … I did move this discussion into its own thread.

#5

Thanks @michalradacz

If the core could observe best practices then at least we would be setting the best example for third party contributors.

Would it help if we added a “title” attribute to the core images (like $:/core/images/close-button)? The approach I had been trying to take was to make those images invisible to assistive technology, and rely on the containing button having a “title” attribute.

#6

Hi, it may be nice to invite some other blind users to this thread if you have feedback from another users too?

#7

Hi everyone, as simple as it can be, these two thinks can rapidly improve accessibility of TW:

  1. Article component for tiddlers, every tiddler can have own ARTICLE layer and it is usefull to determine content containers.
  2. Image descriptions (yes, this will be more difficult, but my idea is, for UI images to put image tiddler name as alt text in represented HTML output). This may be nice for determining some icons and UI images.
#8

It would improve code readability if we, instead of divs, made better use of semantic html tags and custom html tags. It is good practice: This quote is from w3org:

Authors are strongly encouraged to view the div element as an element of last resort, for when no other element is suitable. Use of more appropriate elements instead of the div element leads to better accessibility for readers and easier maintainability for authors.
— HTML Standard

The above quote from w3.org can be found in this nice article on primarily semantic html elements:

Here’s another nice writeup with more focus on custom elements:

1 Like
#9

I can understand the sentiment, but it sure seems the entire industry for the last 20 years has been going in the opposite direction, minimizing special tags and emphasizing CSS.

#10

Keep in mind this is in the context of structured semantic HTML pages <h1>..<h6> etc… which ignores the TiddlyWiki Paradigm of single page multiple tiddlers.

  • I am not completely sure what the implications for accessibility is, but we need to take account of this.
#11

Semantics elements are still useful for screen readers, no ?

For accessibility guidelines, there is also this : Home | Web Accessibility Initiative (WAI) | W3C

#12

I always thought they were a good idea, with or without accessibility concerns – it just seems like the industry doesn’t.

2 Likes
#13

Is there a conflict tho? I’m not sure but the “new” tags that were introduced, are they not without styles (as opposed to older tags like h1, li, etc)? I.e one still needs the CSS, so the main difference is that the html code is a lot clearer and it is smoother to define the CSS.

1 Like
#14

They are also better for SEO: 5 Ways to Write Semantic HTML and Improve Webpage SEO and Accessibility | by Amisha Singh | Geek Culture | Medium

1 Like
#15

Here’s a neat aspect for if TW used semantic and custom tags:

The most “basic” stylesheet in TW would probably be a truly minimal stylesheet and would also would serve as an overview of all the elements that exist! Then any additional stylesheets would use class definitions to override these, because explicit class definitions have higher specificity than the tag element, e.g the following

<article class="foo">one two three</article>

<style>
.foo {background:red}
article {background: green}
</style>

…results in a red background.

(I didn’t fully think this through, but it does feel appealing. Of course, backward compatibility prevents us from doing this any time soon, but it would be neat and, again, much more accessible than today…)

#16

I am for being conscious of using purpose-builds tags when appropriate. But, especially in TiddlyWiki, a lot of the elements injected into the code seem to be there as side effects of widgets being used. Inside those widgets, semantically-appropriate tags could be used if there is certainty that they will always be appropriate.

I keep thinking about the many Spans and DIVs that are created by Keyboard widgets. They really are generic containers that should be ignored by screen readers. If an element is strictly used as a container that could have ever shifting content inside, it seems like the container should be without any implied context. The content author needs to appropriately label (with elements, attributes, etc…) the content inside the generic container.

I have no experience with screen readers, so I don’t know how one handles TW. It makes me nervous to use 5 different Nav or Menu elements on the same page, even if that is most appropriate, as it seems like that could cause more confusion without being able to see the context that may only be visibly-useful.

#17

Yes, this is right exactly for tiddler as container/element, for MAIN (implemented), NAV, ASIDE, etc.

#18

Sorry, but this is irelevant. OSP (one-single-page) is HTML document too and for frontend of reader is it same as website with many pages. But TW is web application, so there is WCAG and WAI-ARIA techniques. And container elements are applicable here too.

#19

WARNING: Structural tags arent old tags, they are mandatory. For example H1, H2, etc are mandatory to ergonimical structure of page content.

I talked about MAIN, ARTICLE, ASIDE, NAV, etc as right alternate method for DIV with ONLY class declaration.

#20

Yeah, by “old tags” I didn’t at all mean that H1, H2 etc shouldn’t be used, I just meant to distinguish them from the tags introduced with HTML5.

1 Like