I am having trouble finding an answer to this. I am trying hard to make sure our site is inclusive so I initially implemented a site-wide letter spacing value of .12rem. However, some managers don't like how it looks and have asked me to reduce or remove it. I told them about ADA compliance so now we have an internal discussion going on about what to do.
Should I not set letter-spacing to a specific value so that each user can handle that on their own if they have a vision disability?
Are there tools available for users to adjust the letter (and word) spacing on a page?
If so, would setting it to a specific value actually make it worse for those tools?
Also, what about word-spacing? Should it be handled in the same way?
If you have any other insight to offer on this topic I would love to hear it. I've been searching online for a while and I am having trouble finding a definitive answer.
Source: https://www.w3.org/WAI/WCAG21/Understanding/text-spacing.html
The Web Content Accessibility Guidelines (WCAG), which is an international standard, does not specify anything about letter spacing or word spacing.
However, it does say that if the user changes their letter spacing (and other spacing requirements) via custom CSS then your page should still render correctly (up to a point). See guideline 1.4.12 Text Spacing
That's probably where you're getting your .12rem from because 1.4.12 says:
"Letter spacing (tracking) to at least 0.12 times the font size;"
The guideline doesn't say that you must use this letter spacing. It says that if the user sets their letter spacing to 0.12 (or less), then the page must still display properly. If the user sets it to 0.13 (or more), then technically it doesn't matter if your page doesn't reflow nicely.
Related
I'm in the process of creating a searchable combobox component. It must be 100% accessible, so I want to tell screen readers how many results there are available when they open the component's options dropdown, and when they are changing its filter term.
The component looks something like this:
I think I will probably need a live region. I know two ways of doing this:
1) role="alert"
This is AFAIK the safest option: it used to work years ago already, and it is pretty well supported by all major browsers (Chrome/Edge, FF) and screen readers (JAWS, NVDA, VoiceOver/iOS, Talkback).
The bad thing: it is "rude", ie. it interrupts the screen reader's current announcement. In addition, some browsers add an ugly "Alert" as a prefix to each such announcement.
So for example, if the options dropdown is expanded (the user presses Down key after focusing the filter input), then two things happen at the same time:
The filter input's aria-expanded is set from false to true, which makes the screen reader announce expanded
The dropdown is now visible, containing a live region with text 4 of 12 options available, starting with "Badminton"
If this live region is a role="alert", then it potentially interrupts (⚡️) the expanded announcement, which feels like a hiccup from the screen reader, ie. expa⚡️ 4 of 12 options....
2) aria-live="polite"
This is the more gentle option: it will append the live region's content to the current announcement of the screen reader (instead of interrupting it), ie. expanded 4 of 12 options....
Sadly, this is not supported with JAWS+Chrome, as far as my tests show - can anyone confirm this? If so, this is extremely lame, taking into account that its the most used desktop combination, and behind both are multi-national (and probably multi-billion) companies.
Conclusion
I can't just use the gentle aria-live everywhere, I need to figure out which browser is used, and if it's Chrome, I need to reside to role="alert".
But there are more problems: there seem to be serious differences between how browsers (and/or screen readers) handle live regions:
Some have problems recognising a live region if it's first hidden (ie. hidden attribute, or display: none) and then made visible. It will then simply not be treated as live region.
Some immediately announce the content of such a made-visible live region, while others just ignore their initial content (they will only announce a change to it).
Some announce a role="alert" element even when it's already there when the page is loaded, others don't (and I think the latter ones are right, because as far as I understand, live regions should announce changes of content, not content that's initially there already)
So this topic is much more complex than I hoped. The simplest solution would probably be the following: just append a visually hidden role="alert" element at the end of the DOM each time an announcement is be made. Then, a few seconds later, remove it again. But this feels ugly to me. I'd rather have my live region right inside my component, where also visible users can see it, or at least parts of it: on the screenshot you can see 4 of 12 options for filter "d", but to screen readers, the same text is announced, plus some more details, ie. starting with option "Badminton". Keeping visual and screen reader announcement in the same place feels like good practice to me, so I will not easily forget about the latter ones, or I will spot some bugs quickly (that would otherwise may be not visible).
So my question is: is there maybe an existing script or library which solves this problem in a solid way and provides optimal experience for the most common browser / screen reader combos?
Thank you.
Polite live regions should be preferred. As you have noticed yourself, alert interrupts current speech, it's rude.
The prefix "Alert!" automatically added might even feel a little scary at times.
As you have noticed, polite live regions are working a little different on each browser + screen reader combinations. Some of these differences are intentional, others are just bugs, and others are simply due to the fact that the official specification doesn't clearly define any particular behavior.
This makes the whole thing, as you have said, actually quite complicated.
Sadly I have no universally working solution. In order to handle all cases, you need to make user agent detection.
Let's look at various issues or points of attention we have with live regions today (in may 2022).
I have no official reference, the following is only my own observations along the years:
Live region detection
A live regions is successfully taken into account as such only when aria-live attribute is present when the element is added to the DOM, and when it is visible by screen readers.
This, in particular, means that it isn't taken into account when the aria-live attribute is set after the element has been added in the DOM, when the element is display:none, visibility:hidden, when attributes aria-hidden or hidden are set, or when the size is 0. Even if hidding attributes are removed later on, it doesn't work.
Announcement time
The only two cases when the content of a live region has to be announced are:
When the element is added in the DOM
When the content of the element has changed
For all other cases, it isn't well defined in the specification. In particular, initial content present directly in HTML code may not be announced, and as far as I have already observed, none of the browsers I have already used ever announce initial content at page load.
Interruptions
When an assertive live region is added, speech is normally always interrupted. Polite live regions updates should never interrupt speech.
However, with many browsers + screen readers combinations, a content currently being read is shut up:
When the aria-live element is removed from the DOM
When its content is emptied
This is for example the case with VoiceOver both under iOS and mac.
So if you have multiple messages to be spoken potentially quick in succession, you shouldn't just replace the older message by the newer one.
You can adopt several strategies:
Simply append new messages to the already existing live region
Create new live regions each time
Clear live region content or remove it from the DOM only if the last messages is older than a few seconds ago
But, be careful, that's not all.
Repeat or not repeat
With some browsers + screen readers combinations, if you simply append new messages to be announced at the end of a live region, the whole content is repeated over and over again from the beginning.
In short, the whole content is read each time there is a change, even parts that haven't changed.
IN theory, the standard provides the two attributes aria-atomic and aria-relevant to control this behavior.
Defaults values are aria-atopic=false and aria-relevant=additions, meaning that only the new content has to be read, and content that hasn't changed shouldn't be read again.
However, in practice:
Chrome with both Jaws and NVDA ignore these attributes completely. The whole content is always read at every change no matter what.
With Firefox and Jaws, the aria-live region no longer works when aria-relevant attribute is explicitly set
With at least some versions of Safari, the aria-live region doesn't work if aria-relevant=additions isn't explicitly set
With some versions of Chrome, if for any reason you want to speak twice the same message, replacing content doesn't work, even if you replace first by the empty string and then by the content again
Are we safe if we create a new live region for each message? Spoiler alert: no!
Announcement order
When several live regions are added to the DOM or updated quickly, nothing says which one has to be announced first.
Safari iOS seem to handle it correctly, i.e. read content in the order of update. I don't know on mac.
With Chrome and both Jaws and NVDA, updating quickly several live regions seem to make them being read in reverse order of their position in the DOM.
Conclusion
At present, it looks like the safest is to create new polite live regions for each message.
You can reuse them, but only if new messages don't arrive too quickly, or if it doesn't matter if they are occasionally interrupted.
For your particular case, I would say that a single reused polite live region is sufficient.
But of course the best is to test as many combinations as possible.
Good luck.
I am new to CSS and web development in general. Hopefully there is a way to accomplish what I am trying to do. What I am trying to do is simple to explain, but I need to give some background info first, sorry for the length of the post.
I have created a webpage that is in the Tibetan language. Tibetan does not have spaces between words, it only has a character called a "tsheg" (་ - U+0F0B) that is used to separate every syllable. It also has a mark called a "shey" (། - U+0F0D) that comes at the end of phrases and clauses and sentences. Although sometimes it is doubled, after a shey is generally a space before the next line of text. When typing in Tibetan this space is represented not as a normal space (U+0020) but instead U+00A0, however when it comes to browsers and HTML/coding in general these two seem to behave the same.
In any Tibetan writing, the ideal aesthetic is for full justification. Traditionally there would be slight spaces placed between the tsheg marks and the shey marks to achieve a perfectly flush left and right alignment. (The exception would be the last line of a text, or a paragraph in contemporary formatting, does not need to be justified). It is acceptable for lines to break mid-word or mid-sentence, but never mid syllable. So the last character on any line is going to be either a tsheg or a shey. It is also not acceptable to start a line with a shey. In the last few years this has been easy to achieve for desktop publishing using MS Word, using "Thai Justification." However that option is not available even in other Office products, never mind outside of the Office environment. Other work-arounds have been to add invisible width characters after every tsheg and shey, allowing for wrapping at any point.
Now comes the question and difficulty. I am using distributed justification, and that seems to be the best option. It does not break syllables up, which is important. But it only wants to break at those spaces after shey marks, and it breaks elsewhere when there is a long string of text without a space, but if there is a space then it breaks there, sometimes stretch one or two syllables across an entire line, which is obviously not ideal.
Now, when coding the HTML of the text I can use the same work-around that is used for desktop publishing pre "Thai justification," I can add a <wbr> after every single tsheg, and this will not be visible to the end user and should allow cleaner breaking. However, there are two problems with this. But inserting that many <wbr> characters I am essentially doubling, or close to doubling, my character count, which can make the page take twice as long to load, even if half of those characters are invisible. However, more important is that it disrupts search functionality. Although you may see the word that has the syllables "AB" for instance, if you tried searching for AB you wouldn't find it, because the HTML sees "AB". And being able to search is kind of critical. Enough so that an ugly formatting is preferable to losing the ability to search and to be indexed properly. Obviously, since I need the site to be responsive and I do not know what size screens will be used I cannot have forced line breaks, either, another trick used when publishing.
So, finally, my question. Is there a way I can define a style or function or some sort of element that automatically associates a certain character--in my case the tsheg character--as having a <wbr> command after it without actually needing to input that command into my HTML? So when the text is justified it treats every tsheg as a <wbr>? I have a class .Tibetan in my stylesheet that defines the font and the justification and so forth, is there some way I can add some code there that achieves what I am looking for?
The one other thing I tried was replacing all of the spaces with which gave a beautiful justified appearance but it also caused the browser to disregard the tsheg marks entirely and it allowed for the cutting in half of syllables.
If you want to see an example of what I am talking about you can visit this page of my site: http://publishing.simplebuddhistmonk.net/index.php/downloads/critical-editions/ and next to the word "English" click the Tibetan characters and that will bring up a paragraph of prose, or you can look here: http://publishing.simplebuddhistmonk.net/index.php/downloads/tibetan/essence-of-dispelling-errors-tib/ (though the formatting on that latter page is less egregious than the former, at least on my screen).
EDIT It looks like the solution this person used might be able to be adapted for my use: Dynamically add <wbr> tag before punctuation however I do not actually understand what I would need to add, and where, to make that work for me. Anyone think that might apply to this scenario? And if so, what code would I add where?
NEW EDIT So, I think the problem might be with the search function that comes from my WordPRess theme. I used my workaround as mentioned above, adding the tag after every tsheg, on this page: http://publishing.simplebuddhistmonk.net/index.php/downloads/tibetan/essence-of-dispelling-errors-tib/ and as you can see, it displays perfectly. But if you search for any phrase from that page using the search function that is up in my header, it will not find it. If you do a Ctrl+F and search on the page, though it will find it. Even if you copy the text from the page and paste it into the search box it still does not find it. Copy the text into a word editor doesn't reveal any hidden or invisible characters. However, if you search for a term from this page http://publishing.simplebuddhistmonk.net/index.php/downloads/tibetan/beautiful-garland-ten-innermost-jewels-tib/ which I have not added the tags to, you will see that it finds it no problem.
So, that leads me to believe the error is in the search function. Any experience with this? Because search is important but I can quite possibly find alternative earch widgets to replace the one that comes with the theme. What is most important though is if you search for a line of text on Google it needs to be found. My site has not been indexed fully by any search engine so I cannot yet confirm if this does or does not affect them.
So.... At this point I wil take any advice I can get. Any advice regarding the original question (is there a way to tell the style guide "if your are displaying X then treat it like X" ) or any idea about this issue with the search functionality, and how the tag may or may not affect search, both from within the site and also from search engines.
I'm enhancing the UI for an application to be more compatible with screen readers. The problem is I keep running into issues and I'm beginning to suspect that it' due to the screen reader itself.
Right now I'm mostly testing JAWS 15 with IE 8 (due to corporate limitations it's basically all I can test with at the moment) and getting some weird behavior, but as near as I can tell the aria markup and html all look correct.
For instance:
In some hidden divs (role="alert") the JAWS does not speak "button" after reading a button's name after the DIV is show. (It does speak "button" once you tab to the button though.)
JAWS is speaking elements with aria-hidden="true," which was fixed according to this thread.
Again with hidden alert divs, in some cases JAWS will repeatedly speak elements. In at least one case it will repeat the header and the first line of text infinitely (or at least until my patience ran out.)
The altText for images in table is not read when the entire page is first read. It does get read when the user navigates through the table with the table commands though. I don't even know what corret behavior is on this one...
I'm basically looking for something where I can find out if these are known issues with JAWS/IE8. And if there's a list of compatibility out there (similar to the HTML5 compatibility list) I'll be able to refer to it whenever people bring these issues up.
http://html5accessibility.com/ is a starting point to discover whether a browser has accessibility support for native elements and attributes.
If you're looking for documentation of screen reader support for ARIA attributes, check out The Paciello Group. For example, Steve Faulkner published a post on role=alert that may be helpful.
Recently I've seen a wide usage of dotted and dashed hyperlinks in a variety of Russian Web 2.0 websites. Normally such links (which have a dashed or dotted line underneath them, instead of a normal solid line) don't lead a user to another page, but rather perform an action on the same page without reloading it.
As an example, such links can fold/unfold information blocks, or switch between sorting order of page elements.
So I'm wondering: are such links used in the same way in the bigger internet?
Also, are there any articles or books which describe standard look&feel for hyperlinks depending on the action they perform?
There was a time, way back in the day, when a few folks tried to stick with the idea that dashed underlines were for contextual help. I think that was a carry over from old Windows help files.
But, since then, no, there is no rule or standards as to what the style of underline means in a hyperlink. For better or worse, the underline, itself, isn't even a standard anymore as lots of sites forgo them (which, IMHO, is more often than not a bad idea).
All that said, I do like the idea and the attempt and differentiating on-page interaction vs. a link that actually takes you somewhere else.
I think it's just a matter of style and taste.
Personally, I wouldn't do it. Traditionally, hyperlinks are blue and underlined (or get underlined on mouseover). It helps the users navigate swiftly through the page without thinking much. If you have your links green and overlined, it works just as well but in my opinion, it's less user-friendly (for a new visitor).
Unless it has a special meaning on your site, of course.
The dotted underline is -as far as i know- traditionally used for the acronym tag.
The normal format for hyperlinks is 'http://web.site.com/path/to/my/content?arg=value&arg2=value2#hashtag'. For relative links, parts of the URL are optional.
Technically, dots and dashes are acceptable in almost every part of a URL. It is unusual to see dots in the path, but dashes are quite normal (see the URL for this page, for instance). Dots and dashes are both uncommon in query parameters (the arg=value part), but should work. It is very common to see both dots and dashes in the hashtag, which is what I believe you were referring to.
The purpose of the hashtag is traditionally to link to a location within a web page, marked by an anchor tag () with a name attribute. In modern webapps, the hashtag is used as a 'bookmark' for a particular view in the app -- in GMail, for instance, the hashtag is used to mark which label and message you are viewing. There is no established norm for what is an appropriate hashtag. You should use whatever makes sense for your app. A human-readable tag is usually preferable, as it gives the user a better understanding of what the URL means, but it is certainly not required.
Find the following in the CSS of the page -
border-bottom: 1px dashed #05C;
It's just a style override for the default underlining.
Accessibility is important to me as I'm a physically disabled developer. I'd like to make sure I have a good feel for what it takes to make a site accessible while also being pointed in the right direction for the things I'm uncertain with, or just haven't considered. So, here's what I'm comfortable with right now:
Alt text for images with meaning.
Percentage or font-relative measurements (ems) for those who need to re-size their screens.
Colors with good contrast for those with colorblindness.
Textual representation of any audio/visual material.
Questions:
Should I make a link at the top of the site to jump down to content on every page?
How is JavaScript handled by screen readers?
Is there anything major I'm missing?
WebAim.org is a great resource for all things web-accessibly related. Suggest starting off with their WCAG (Web Content Accessibility Guidelines) checklist.
Quick answers to your qu's:
Should I make a link at the top of the site to jump down to content on every page?
This is currently recommended best practice. (Eventually HTML5 semantic tags will remove the need for this, but we're not there yet. One thing to watch for: if you do use a hidden link, be sure to make it visible again when it has focus, so that sighted keyboard users don't get 'lost'.)
How is JavaScript handled by screen readers?
All depends on what you use it for. The main area for problem is if new content appears that the user is supposed to be aware of (eg. popups, expanding blocks); if it doesn't get keyboard focus, a screenreader may not read it out to the user and the user may not realize that anything has changed. This is one area where it may be necessary to test with a real-world screenreader (eg. NVDA or JAWS) to ensure that it's actually usable. A simple approach is to only have UI appear in response to user request: eg user hits return on a menu item to make the menu appear, don't make it appear merely in response to it getting focus. Then when it does appear, set focus to the first item: this is both expected behavior for menus in most UIs, and changing the focus typically also causes the screenreader to read out the new item, which confirms to the user that something has happened. (Also, if using Javascript to add behavior to existing elements - eg. make a link behave like a button - use WAI-ARIA attributes such as role="button" to let the screenreader know what the intent is so it will read out that role to the user, and will say 'button' instead of 'link'.)
Is there anything major I'm missing?
I think you've got most of the key points already covered above; the WCAG checklist should fill in everything else. One major area that is worth mentioning is to use headers (H1, etc) appropriately. For screenreader users, navigating by header is a major way for navigating a page. Typically when navigating to a page that a user hasn't visited before, the user will hit a hot-key to get the screenreader to bring up a list of headings on that page as a way of 'skimming' to get an overview. Having good link text is also important; ideally links should be self-describing, so you don't just hear "click for more", "click for more" as you tab through a page.
For newer browsers, IE8, IE9, Firefox 3?, and Safari 5 (possibly 4), and newer screen readers WAI-ARIA is the way to go. Among other things it has landmark roles which if you have an ARIA reading screen reader, such as JAWS 12 and possibly JAWS 11 and 10, the screen reader can use to jump around. It can get a bit clunky if you want things to be backwards accessible but is the direction the web is going in. Their are many other advantages to ARIA but that's the one relevant to your question. On a related note VoiceOver for the Mac is supposed to be ARIA compliant as well.
I'm not disagreeing with the selected best answer, but I would spend more time learning about WCAG 2.0 than with the original WCAG specification. Both in the United States and internationally, the Web Content Accessibility Guideline 2.0 are quickly becoming the standard. In fact, the Access Board, the group tasked with defining the guidelines for Section 508, are refreshing the standards to be harmonized with WCAG 2.0.
You can find great information by starting here Web Content Accessibility Guidelines (WCAG) 2.0.