I have a lengthy document that I need to convert to WCAG AA compliant HTML and the author used asterisks as end notes like *, **, and ***. Here is an example:
Solano County Atlas Fire (Solano County) 10/17*
Ponderosa Fire (Butte County) 08/17*
Helena Fire (Trinity County) 08/17*
...
* For taxable years beginning on or after January 1, 2014...
NOTE: multiple * asterisks in the above list all point to a single end note reference making it difficult to use traditional footnote practices.
Below is my attempt to solve this using aria-describedby, however JAWS does not read the description asterisks or the description at all.
Solano County Atlas Fire (Solano County) 10/17<span aria-describedby="dd1">*</span>
...
<p id="dd1">* For taxable years beginning on or after January 1, 2014...</p>
After some research it appears that JAWS and some other screen readers do not announce some punctuation at all. So I am not sure how exactly to go about fixing this. I am not really at liberty to change the characters unless there is no other possible solution.
What would you suggest I do to fix this?
I'd suggest to do a simple thing, as it is done in quite a number of books in HTML I read.
Make your asterisk a link with an Id, i.e., <a id="linkToNote1" href="#note1">*</a>.
Add a heading called "Notes" to the end of the document.
Add notes either as list items or as paragraphs with corresponding Ids (in this case, note1).
The most important: End each note with a link leading back to the appropriate place in the text, i.e.: Go back.
If however you want to use ARIA, do not mark the only asterisk with aria-describedby since you're right in that many users set their punctuation level quite low so they are not distracted by those signs in a lengthy text.
Related
I am a student and brand new to HTML. We are making websites and I am trying to figure out how to code the "#" symbol into my page.
I originally in one of my paragraphs wrote "The game is located # etc." But I want to put it as "The game is located (# entity) etc"
Character references are useful when the character you want to use
has special meaning in HTML
does not appear in ASCII (and you are stuck on an 20th century system that doesn't use UTF-8)
doesn't appear on a standard keyboard so it hard to type (but copy/pasting is still usually a better bet)
could be confused with another similar looking character (e.g. a space vs a non-breaking space)
None of those apply to the # symbol. You should just type #.
That said, if you really want to use an entity, it is:
@
It takes 8 characters (and bytes) instead of 1.
As #Quentin has already indicated, you can use the HTML escape @ which is the same as both # and simply typing # on your keyboard and is represented in Unicode as U+0040.
However, there are, additionally, two more at symbols in Unicode, full-width and small:
U+FF20
U+FE6B
For which the HTML escapes are:
＠
﹫
Example:
<h2>Standard <code>#</code> symbols</h2>
<ul>
<li># <code>[TYPED FROM KEYBOARD]</code></li>
<li>@ <code>[@]</code></li>
<li># <code>[@]</code></li>
</ul>
<h2>Alternative <code>#</code> symbols</h2>
<ul>
<li>＠ <code>[＠]</code> <em>full-width</em></li>
<li>﹫ <code>[﹫]</code> <em>small</em></li>
</ul>
I have following layout in my web application:
To make it accessibility compliant, is there a need to relate "Al Allbrook" with "Requester" label? If so, how we can achieve that?
"Al Allbrook" is a link to user profile.
If they are not related, how come srceen reader will know "Al Allbrook" is a requester? Same in case of "Site".
In additon to what #andy said, you could also use a table. The first column could have a "requestor" table heading (<th scope="col">). The heading itself could be visually hidden if you don't want it to "clutter" the display but still be available to screen reader (SR) users. The second column would be something like "contact info" and the last column is "site". This allows a SR user to navigate across the row of the table and they'll hear the column heading before the data cell.
Of course, you can do a combination of these techniques. Have a table and have extra information on the links. I would recommend aria-labelledby instead of aria-describedby. While both attributes will cause the extra information to be read by a SR (*), only the aria-labelledby attribute will be displayed in the list of links.
(*) Some SRs announce the aria-describedby attribute directly but other SRs will just tell you that there is a description associated with the link and you have to hit a different shortcut key to hear the description.
The nice thing about both attributes is that the element can refer to itself as part of the label. Kind of a recursive labeling but the "Accessible Name and Description Computation" rules handle the recursion.
if computing a name, and the current node has an aria-labelledby attribute that contains at least one valid IDREF, and the current node is not already part of an aria-labelledby traversal, process its IDREFs in the order they occur
It's probably easier to see an example of this.
<span id="comma" style="display:none">,</span>
...
<span id="requestor">Requestor</span>
Al Allbrook
Several things to note.
First is that the link is referring to itself in the aria-labelledby attribute (the 'myself' id).
Second is that I'm using a trick with screen readers by adding a comma in the label, "Al Allbrook, Requestor" so that the SR has a slight pause when reading the label, "Al Allbrook <pause> Requestor", rather than hearing it as if the guy's name was "Al Allbrook Requestor". Note that the comma itself has display:none so it's not visible, but since the comma element's ID is listed in aria-labelledby, it'll still be used. (See rule 2A in the Accessible Name url above)
Lastly, my example used a <span> for "Requestor" but you might want it to be a heading (<h3> or <h4> or whatever level is appropriate) instead.
For example:
<span id="comma" style="display:none">,</span>
...
<h3 id="requestor">Requestor</h3>
Al Allbrook
And then all this code could be in a <td> if you're using a table.
There is different ways to navigate through a site with a screenreader, so it depends on the navigation mode the user is using at the moment.
In DOM order
In this case, if your "Requester" is before the link in DOM, it will be read before the person's name. Also, the text right before and after a link can be read by means of certain shortcuts.
By accessing a list of links
There is different lists screen reader users can request, f.e. list of all headers, or a list of all links on the page.
If it's important to you to have the "requester" read when navigating to the link directly, you can link the two elements by means of aria-describedby or aria-labelledby.
Alternatively, you could add the text again to the link itself, hidden visually. Like "Al Allbrook, Requester".
I'm creating a content heavy page that is broken up into several small chunks of content. I want this content to be structured in a way that is accessibility friendly.
I originally planned on using the label tag for each piece of content but from what I understand, they are for form elements only. I'm using a series of header (h2, h3, h4...) tags for the main structure of the content but I'm a bit confused as to what I should use for the frequent chunks of short content that needs to be labeled i.e.: Work phone, Home phone, Membership type.
What element should I use to label one-liner pieces of content?
My main concern is how screen readers will digest the content.
I'm laughing to myself at how much effort I'm putting into something as simple as HTML.
Often natural language already conveys what you want to say, without needing any special element:
My work phone: 000
For other cases (or if you want to make cases like the above one explicit), especially if you have a set of name-value groups, and you don’t want to phrase natural sentences, you could use the dl element:
<dl>
<dt>Work</dt> <dd>000</dd>
<dt>Home</dt> <dd>111</dd>
</dl>
The shortest answer to your question is: use microdata.
However, "microdata" has evolved quite a lot over the 10 years - various markup standards have emerged - earlier microformats like hCard, hCalendar & hRecipe and later, more sophisticated initiatives like RDFa, schema.org, JSON-LD - and all have continued to grow and change.
The answer below addresses 2 specific considerations:
How to make telephone numbers immediately apparent to user-agents like browsers and screen-readers.
How to (begin to) establish semantic differentiation between different telephone numbers on the same web-page.
1. Adding Interactivity to Telephone Numbers in mark-up
To assist screenreaders, you can mark up telephone numbers in HTML5, using a syntax similar to the mailto: email address syntax:
Email: me#example.com
Tel: 429-566-3674
N.B. The number stated in the tel: link must begin with a +, immediately followed by the international dialling code.
The HTML above will also add interactivity to your marked-up telephone number.
eg. It will enable smartphones to start calling the number when you click on it in a mobile browser. It will also enable (some) permitted VOIP programmes to start calling the number, when you click on it in a desktop or laptop browser.
=====
2. Distinguishing Home Phone numbers and Work Phone numbers in mark-up
The HTML above will not explicitly distinguish between Work Phone numbers and Home Phone Numbers.
You can start to build such a distinction by employing a microdata vocabulary like that found at http://schema.org/:
<div itemscope itemtype="http://schema.org/Person">
<h2 itemprop="name">Alice</h2>
<dl itemprop="contactPoint" itemscope itemtype="http://schema.org/ContactPoint/">
<dt itemprop="contactType">Home:</dt>
<dd itemprop="telephone">429-677-4785</dd>
<dt itemprop="contactType">Work:</dt>
<dd itemprop="telephone">429-566-3674</dd>
</dl>
</div>
I'm attempting to develop a regular expression that can be run in Sigil, the ePub 2 editor.
Small-caps are a well-known problem within the current ePub reader ecosystem. Many readers, such as Adobe Digital Editions, do not support "font-variant: small-caps". After trying several different workarounds, I've settled on creating fake small caps by transforming the text to uppercase and setting the previously lowercase letters to "font-size: 0.75em".
This process is extremely tedious, especially when working with books that have lots of endnotes with citations of other books.
Say that I have a bunch of phrases in an HTML page tagged with an "SC" class. I've created a test phrase:
<span class="SC">Hello World! Testing: one tWo thrEE & W.T.F.</span>
<span class="foo">Don't touch me!</span>
The goal is to write a regex that matches any lowercase letters within the "SC" span tag only, and replace them with:
<span class="FSC">LETTERS</span>
I can manage to match and replace the letters in the first word "Hello", but everything breaks down after that.
Here's what I've got so far:
Find:
(<span class="SC">.*?)([a-z]+)(.*</span>)
Replace:
\1<span class="FSC">\U\2\E</span>\3
The tricky part is then continuing to find the rest of the lowercase letters within that tag, now that a new "FSC" (Fake Small Caps) span tag has been introduced. Trying the same regex again results in "span" and then "class" getting the FSC treatment. Ideally, I'd like to be able to just keep hitting the "Replace All" button until no more matches are found.
The above example would look like this when finished:
<span class="SC">H<span class="FSC">ELLO</span> W<span class="FSC">ORLD</span>! T<span class="FSC">ESTING</span>: <span class="FSC">ONE</span> <span class="FSC">T</span>W<span class="FSC">O</span> <span class="FSC">THR</span>EE & W.T.F.</span>
<span class="foo">Don't touch me!</span>
It's not pretty, but it works on every ePub reader that I've tested it on.
If you google "epub small caps regex", you'll come across a MobileRead wiki article that I edited to include this regex, which I've decided is not satisfactory:
(<span class="[a-zA-Z0-9\- ]*?(?<!F)SC[a-zA-Z0-9\-]*?">(?:.+?<span class="FSC">.+?</span>)*[\.|,|:|;|-|–|—|!|\?]? ?(?:&)? ?[A-Z]+)([a-z'’\. ]+)(.*?</span>)
This ends up miniaturizing a bunch of punctuation and sometimes stops in the middle of a phrase. I started over, thinking there was probably a better solution that doesn't attempt to plan for every single possibility up front.
If someone comes up with a better solution to this, you'll be the hero of the entire ePub publishing industry.
Update
I've added the accepted (and only) answer to the Mobile Read wiki. Please note that this regex has been altered specifically for use in Sigil; YMMV in other environments.
Perfect usecase for: Collapse and Capture a Repeating Pattern in a Single Regex Expression
Modified it for your case:
(<span class="SC">(?:(?!<\/span>)(?:[^a-z&]|&[^;]+;))*|(?!^)\G(?:(?!<\/span>)(?:[^a-z&]|&[^;]+;))*)([a-z]+)
Replace with: \1<span class="FSC">\U\2\E</span>
And here's the RegEx explained: http://regex101.com/r/jU6bA5
This is a solution for "Replace All" as it works via RegEx global modifier /g !
Since HTML5 does not support Microsoft's <acronym> tag, we're left with using the abbreviation element:
<abbr title="Microsoft">MS</abbr>
When it comes to capitalization, cases like that are obvious: it needs to be capitalized.
However, what about other contexts where the word itself isn't usually capitalized in context?
For example:
<p>What is a <abbr title="chief technical officer">CTO</abbr>?</p>
That seems to be fine if one were to switch the title and actual text around.
But when hovering the mouse, it looks a bit odd:
The same goes for:
<p><abbr title="Chief technical officers">CTOs</abbr> are usually skilled technically.</p>
It makes sense if the abbreviation and actual text were switched around, but hovering also looks a bit "weird":
Now, what if we capitalize abbreviations as if they were titles?
For example:
<p>Wouldn't capitalizing <abbr title="Away From Keyboard">AFK</abbr> look weird?</p>
It would if the the title was substituted for the abbreviation, but on mouse-over it seems to look "better":
But what is right semantically?
The replacement text should reflect what the real text would be if it were substituted. Acronyms are generally not constructed from proper nouns, therefore the replacement text should be in all lower-case.
You'd never actually type "Chief Technical Officers" (unless you mistakenly thought they were proper nouns).
From the Chicago Manual of Style
Civil, military, religious, and professional titles are capitalized when they immediately precede a personal name and are thus used as part of the name (typically replacing the title holder’s first name). In formal prose and other generic text (as opposed to promotional or ceremonial contexts or a heading), titles are normally lowercased when following a name or used in place of a name
So it seems clear that you shouldn't capitalise CTO's (unless you mean the Central Treaty Organization).
I don't share your concern - the uncapitalised versions look fine to me. If it is for tooltip-style popups you could mandate all lowercase as house style.
and Away From Keyboard really does look weird...
(forgive my mixed spelling, uk-english quoting us-english...)