Accessible Text

Café
#1

This popped into my work inbox.
The Basics of Accessible Documents

and I wondered what we can do in TW to make our docs more accessible, best practice and all that.

3 Likes
#2

Thanks for this link. Documentation, in particular, needs this kind of care.

Most of this advice I like very much, and appreciate. I was aware that we could specify descriptions for images, but I didn’t know there’s a way to mark an image as just decorative. I think I could do better at using headings (and other semantic tags that screenreaders prefer) rather than various inline techniques designed for visual scanning.

A couple things I’m flummoxed about. In particular the “don’t merge cells in tables” advice — since following that advice can make certain information less salient for those with visual access, even if screen-readers don’t (yet?) have a good way of expressing that info.

Still, I second your call to think about tiddlywiki documentation.

There’s a website, colorblindly, that allows us to simulate how a website comes across for visitors with common forms of coloblindness: https://chromewebstore.google.com/detail/colorblindly/floniaahmccleoclneebhhmnjgdfijgg

I realize I should similarly do some trials on my sites to see how they are handled by screen-reading software. :thinking: Surely some experimentation is worth more than a list of rules, especially with a platform like TiddlyWiki that has different affordances from most websites… In particular, I’m curious how well a screen-reader can cope with the internal-toc presentation structure that I use when I teach, or the tabbed panels used often in TiddlyWiki documentation.

1 Like
#3

Some links

<!DOCTYPE NETSCAPE-Bookmark-file-1>
<!-- This is an automatically generated file.
     It will be read and overwritten.
     DO NOT EDIT! -->
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8">
<meta http-equiv="Content-Security-Policy"
      content="default-src 'self'; script-src 'none'; img-src data: *; object-src 'none'"></meta>
<TITLE>Bookmarks</TITLE>
<H1>Bookmarks Menu</H1>

<DL><p>
    <DT><H3 ADD_DATE="1584415214" LAST_MODIFIED="1710336516" PERSONAL_TOOLBAR_FOLDER="true">Bookmarks Toolbar</H3>
    <DL><p>
        <DT><H3 ADD_DATE="1708447688" LAST_MODIFIED="1710084472">Accessibility</H3>
        <DL><p>
            <DT><H3 ADD_DATE="1709748272" LAST_MODIFIED="1710084399">ACRT</H3>
            <DL><p>
                <DT><A HREF="https://section508coordinators.github.io/ACRT/index.html" ADD_DATE="1710084399" LAST_MODIFIED="1710084399">ACRT Home</A>
                <DT><A HREF="https://github.com/Section508Coordinators/ACRT" ADD_DATE="1710084352" LAST_MODIFIED="1710084352">GitHub - Section508Coordinators/ACRT: This repository stores files for Accessibility Conformance Reporting Tool (ACRT) tool. This tool is standalone browser based application and is used to track accessibility test results.</A>
            </DL><p>
            <DT>Executable bookmarklet/plugin: <A HREF="javascript:void((function(){andiScript=document.createElement('script');andiScript.setAttribute('src','https://www.ssa.gov/accessibility/andi/andi.js');document.body.appendChild(andiScript)})());" ADD_DATE="1696172455" LAST_MODIFIED="1710083738">ANDI</A>
            <DT><H3 ADD_DATE="1710084442" LAST_MODIFIED="1710084472">508</H3>
            <DL><p>
                <DT><A HREF="https://www.section508.gov/" ADD_DATE="1708656390" LAST_MODIFIED="1710084472" >Home | Section508.gov</A>
                <DT><A HREF="https://www.dhs.gov/508-testing" ADD_DATE="1710084422" LAST_MODIFIED="1710084455">Section 508 Testing | Homeland Security</A>
                <DT><A HREF="https://www.dhs.gov/508-training" ADD_DATE="1709747701" LAST_MODIFIED="1710084451">Section 508 Training | Homeland Security</A>
            </DL><p>
            <DT><A HREF="https://webaim.org/" ADD_DATE="1708447722" LAST_MODIFIED="1708447722" >WebAIM: Web Accessibility In Mind</A>
            <DT><A HREF="https://wave.webaim.org/" ADD_DATE="1709130443" LAST_MODIFIED="1709130443">WAVE Web Accessibility Evaluation Tools</A>
            <DT><A HREF="https://developer.mozilla.org/en-US/docs/Web/Accessibility/Understanding_WCAG" ADD_DATE="1708447854" LAST_MODIFIED="1708447854" >Understanding the Web Content Accessibility Guidelines - Accessibility | MDN</A>
            <DT><A HREF="https://webaim.org/techniques/keyboard/" ADD_DATE="1708447707" LAST_MODIFIED="1708447707">WebAIM: Keyboard Accessibility</A>
            <DT><A HREF="https://silktide.com/tools/toolbar/" ADD_DATE="1708447765" LAST_MODIFIED="1708447765" >Accessibility Checker for Chrome - 200+ Free WCAG Checks</A>
            <DT><A HREF="https://www.w3.org/WAI/ARIA/apg/" ADD_DATE="1709215304" LAST_MODIFIED="1709215304">ARIA Authoring Practices Guide | APG | WAI | W3C</A>
            <DT><A HREF="https://www.section508.gov/sell/vpat/" ADD_DATE="1709223648" LAST_MODIFIED="1709223648" >Voluntary Product Accessibility Template (VPAT®) | Section508.gov</A>
            <DT><A HREF="https://www.section508.gov/content/guide-accessible-web-design-development/" ADD_DATE="1709215354" LAST_MODIFIED="1709215359" >Guide to Accessible Web Design &amp; Development | Section508.gov</A>
            <DT><A HREF="https://www.section508.gov/develop/web-content/" ADD_DATE="1709215383" LAST_MODIFIED="1709215383" >Developing Accessible Web Content | Section508.gov</A>
            <DT><A HREF="https://www.w3.org/WAI/test-evaluate/tools/list/" ADD_DATE="1708447751" LAST_MODIFIED="1708447751">[Draft] Web Accessibility Evaluation Tools List | Web Accessibility Initiative (WAI) | W3C</A>
            <DT><A HREF="https://universaldesign.ie/about-universal-design/the-7-principles" ADD_DATE="1709223923" LAST_MODIFIED="1709223923" >The 7 Principles - Centre for Excellence in Universal Design</A>
            <DT><A HREF="https://duckduckgo.com/?t=ffab&q=accessibility+tools&ia=web&atb=v267-1" ADD_DATE="1708447734" LAST_MODIFIED="1708447734">accessibility tools at DuckDuckGo</A>
        </DL><p>
    </DL><p>
</DL>

Because (for whatever reason :roll_eyes:) this forum doesn’t allow, .txt, .html or even .zip attachments, you’ll have to scrape it and save to HTML yourselves. It’s a dump from my bookmarks in Firefox, covers Section 508, WCAG etc.

2 Likes
#4

Really?

accessibility tools at DuckDuckGo

#5

I converted your links to markdown (using this addon) for convenience:

ACRT

javascript:void((function(){andiScript=document.createElement('script');andiScript.setAttribute('src','https://www.ssa.gov/accessibility/andi/andi.js');document.body.appendChild(andiScript)})());

508

3 Likes
#6

The first point in the linked articles: use proper heading styles. I find this difficult to adhere to in TW, tw-com is also inconsistent in this matter.

The site title in the sidebar is h1, this makes sense.
The tiddler title in view template is h2, this too makes sense.
By this logic, the highest header used in tiddler body should be h3.

The editor toolbar buttons shown by default are h1, h2, and h3, but theoretically we should only use h3, h4, h5, and so on.
TW-com uses h2 in tiddler body in HelloThere, but usually h1 in documentation tiddlers.

I usually use h2, because I find it most visually appropriate: h1 appears too large (almost or the same as tiddler title), and h3 doesn’t stand out enough. I rarely go for h3 subheading of h2, and I have never needed h4 so far.

It doesn’t matter much to me what I use as long as it looks reasonable. But for the sake of consistency and accessibility, it would be nice if there was an officially recommended consistent approach to this. The logical consequence of h1 site title and h2 tiddler title would be h3 headings in tiddler body, but this discouraged through the default choice of buttons and styling.

2 Likes
Should caption be displayed as main title?
#7

I’ve noticed this point and struggled with it, too.

In this recent thread I was picking up on that <h2>= tiddler-title standard:

1 Like
#8

There is a way to “rebalance these” that had being discussed in the past.

One thing to keep in mind that tiddlywiki is different. One could argue that a tiddler is a page, that in other html websites would have to be a separate HTML and would start and H1 again.

Using Zoom in and out is sufficient for me personally, resizing, I use H2 at the top of a tiddler but still want the capacity to have content of the size matching the title.

#9

One thing I’d like to add is a request to support aria-labels in more widgets.

I see only the button and link widgets support this, but if you’re making a website with TiddlyWiki and you have text fields with labels, it would be nice to enable screen readers to read your labels. Correct me if I’m wrong, but as far as I can tell, at the moment you can add labels to input fields visually (by simply writing things like <em>Phone Number:</em><br> before your <$edit-text> widget, but there’s no way of making screen readers identify the <$edit-text> widget as the “Phone Number” field.

#10

I am no expert here but look at other options here Accessibility Labels and consider wrapping something in a span etc… with an aria label?

#11

Aria labels are read by screen readers when the element labeled receives focus, so putting the aria label on a non-focusable element (such as span) won’t do anything as far as I know.

The <label> element is the most semantically correct, but because we can’t assign id attributes via the edit-text widget, we can’t use the label elements “for” attribute.

So the only option is to make the $edit-text (or other input) widget be a child of the label, since this is an alternative way of associating the label with the input without using the “for” attribute:

<label>My label<$edit-text tag="input" tiddler=<<myTiddler>>/></label>

The label element permits “phrasing content” (such as spans), so to style the label, you can do something like this:

<label><span class="label label-above">My label</span><$edit-text tag="input" tiddler=<<myTiddler>>/></label>

(You could use .label to add font-weight bold and .label-above to add display block or some other way of making the element display above the input element instead of inline with it.)

This still falls short of what is needed, because there are times when you need to label an input for screen readers without displaying it for visual users (when the visual context makes it obvious what a field does, often the case for search bars, for example). This is the use case for aria-label, but…

I did find a workaround, I think. Unfortunately it’s not so simple as display: none, because this not only hides the content from users, but also instructs screen readers to ignore that content. However, you can use more convoluted CSS to hide content without explicitly disappearing it, by clipping it down to nothing and removing any padding, margins, etc. (Looks like the key property in that link is deprecated, but clip-path will probably work just as well.)

So if your CSS class for clipping your label is “.screen-reader-only” then you could write:

<label><span class="screen-reader-only">My label</span><$edit-text tag="input" tiddler=<<myTiddler>>/></label>

Due to the abuse of CSS required to make this work, I believe adding aria-label support for more widgets is a much better solution.

#12

This is not really a cafe discussion, Perhaps create a new thread in discussion topic. Others have handled this in the past.

#13

Oh, you’re right! I didn’t even notice the category, my apologies.