accessibility support for links

[Jean-Pierre Rivière]

I am professionally concerned by a11y problems, checking website or webapps for compliance to WCAG rules. Being French, this means following RGAA for me, but this is only a facilitating tool for WCAG.

Whatever. I came upon two points that meant my support tw for RGAA stuff, being in French, should mention that outer links to WCAG stuff be in French. The standards linking doesn't allow for this. I wrote my own macro to elaborated a custom <a> link. But definitely, if I had to recover all the specifics of the standard linking mechanism, my macro would have been much more complex! So I think the standard markup (or at least the $link widget) should allow for specifying the language of the linked page.

BTW, my (crude!) macro:

\define enLink(label, url) <a href="$url$" lang="en">$label$</a>

an example of use (not too much of a hassle to write compared with [[label|url]] indeed):

<<enLink "WAI-ARIA 1.1 Authoring Practices" "https://www.w3.org/TR/wai-aria-practices-1.1/">>

(where it was shown I didn't need anything else for accessibility requirements for the kind of links I used within my project)

[Jeremy Ruston]

Hi Jean-Pierre

The <$link> widget is only used for internal links, which I assume are not covered by the directive?. The usual [ext[link syntax]] or [[https://example.com/]] for external links generates an <a> tag, so the macro you’re using would be the recommended solution for a case like this.

Best wishes

Jeremy

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/0f5fb8b2-a909-4aad-86fe-82666e392adbn%40googlegroups.com.

[Jean-Pierre Rivière]

You're right for external link. Though something like [[label|external URL|hint text|language of target]] would be solving nearly all cases.

And, there can be cases where a wiki has pages in several languages, meaning that $link would be nice to offer that possibility too. and the [[...]] notation would be the very same than above.

As for the hint text, this is also something that may have to be set for accessibility reasons.

[PMario]

Hi,

On Friday, November 20, 2020 at 5:44:27 PM UTC+1 jn.pierr...@gmail.com wrote:

...

You're right for external link. Though something like [[label|external URL|hint text|language of target]] would be solving nearly all cases.

 

If I understand this https://www.boia.org/wcag2/cp/3.1.2 right it's not language of target, that needs to be defined. If the link has a label, that is a different language it has to be defined for the label. In most cases the target document will be that lang too. But it may be different.

-m

[Jean-Pierre Rivière]

@ PMario, you're right. But there is few difference because most of the time, a link to a foreign language will have a label in that language too. In RGAA 4, we have:

Par exemple un lien affecté d'un title en anglais devra comporter un attribut lang="en". The lang attribute is for the label, not for the document. I read too fast. Thank you for correcting me.

There is a similar need when the foreign language change the sense of reading with either LTR or RTL and the same logic applies.

What also may be needed, as I wrote elsewhere, is an hint text in case where the label or the eventual picture is not explicit enough. And this might be the case for internal link. that could be addressed with a syntax like [[label|title|hint]] where |hint could only be the third field, which may mean to duplicate label if label is the title, as in [[foobar|foobar|helpful hint, isn't it?]].

Regards.

[PMario]

Hi Jean-Pierr,

I think there are some "low hanging fruits" as you pointed out. Eg: we can check our widgets, if all of them have a "tooltip" parameter, which will be easy to implement as a custom link-macro, as you did. eg: <<link lang:en tooltip:"some text">> ... so every user can define it according to the use-case.

eg: those widgets don't have tooltips.

RevealWidget

RangeWidget

RadioWidget

ListWidget

CheckboxWidget

They should be easy to implement except for the "list-widget"

-mario

[Hans Wobbe]

Mario:

I think that is a very good suggestion since it would be relatively easy to implement and would provide significant "hacker" value.

Best regards,

Hans

[PMario]

On Saturday, November 21, 2020 at 4:44:33 PM UTC+1 hww...@gmail.com wrote:

I think that is a very good suggestion since it would be relatively easy to implement and would provide significant "hacker" value.

Hallo Hans,

Yes. I did test TW a little bit with the build in screen reader in Win10. ... The experience with the default layout is horrible. There are way to many buttons and almost no possibility to actually read a tiddler content. .. So we would need a whole new interface.

IMO The main problem is, that all the devs don't really need accessibility support. So we don't understand what it needs to be a convenient experience.

just a thought

mario

[Eric Shulman]

On Saturday, November 21, 2020 at 7:12:55 AM UTC-8 PMario wrote:

eg: those widgets don't have tooltips. 

RevealWidget

RangeWidget

RadioWidget

ListWidget

CheckboxWidget

see https://groups.google.com/g/tiddlywiki/c/O9hEbpWRQAU/m/8HZ9s3QTBAAJ, which describes how to add a tooltip to *any* content by using <span title="tooltip text here">...</span>

Note also that you don't actually interact with RevealWidget or ListWidget.  These are typically used to affect a conditional display of content based on the value of a "state" tiddler.

-e

[PMario]

Hi Eric,

On Saturday, November 21, 2020 at 5:05:12 PM UTC+1 Eric Shulman wrote:

see https://groups.google.com/g/tiddlywiki/c/O9hEbpWRQAU/m/8HZ9s3QTBAAJ, which describes how to add a tooltip to *any* content by using <span title="tooltip text here">...</span>

That's OK, but I'd consider it a workaround.

 

Note also that you don't actually interact with RevealWidget or ListWidget.  These are typically used to affect a conditional display of content based on the value of a "state" tiddler.

That's right. I was thinking about "interactive macros" that are used at tiddlywiki.com and elsewhere. .. We should have a closer look at them.

mario

[Hans Wobbe]

Eric: Thank you for those reminders.

Mario: I think you Your point about "accessibility support" may be encompassed in a more generalized "customization" solution.  I'm not sure just how distracting Canada's growing CoVid problems are likely to become, but if they free up even a bit of time, I'll try to experiment a bit more.

-h