W3C’s WAI Creates Perspectives Videos for Accessibility Understanding

an image of a man with burned toast
Just as we all like different degrees of doneness in our toast, users need to be able to change the way text is displayed — changing the size, spacing, font, color, and more — in order to read the text. When text is changed, no information or functionality should be lost, the text should re-flow, and users shouldn’t have to scroll horizontally to read sentences.

A wonderful new resource from the W3C is a set of very short videos called Web Accessibility Perspectives. The videos take a particular aspect of web accessibility such as keyboard compatibility or clear layout and design and show how they are essential for people with disabilities and useful for everyone.

I picked one at random, the text to speech one, to share here. There are 10 videos in all. They are perfect for use in a class about accessibility or just for learning something about web accessibility if you’re trying to understand it yourself.

 

 

Summary: How to Apply WCAG 2.0 to Mobile Devices

This slideshow requires JavaScript.

This post simply serves as a summary of the 4 posts published recently that distill the information from the W3C about how the guidelines and principles of WCAG 2.0 apply to mobile devices.

I thought it would be useful to have a single post with links to each of the previous posts. The posts take the 4 POUR principles and explain what they mean in terms of mobile application.

POUR

Mobile Accessibility and the Perceivable Principle

Mobile accessibility and the perceivable princple

The W3C wants to help developers understand how WCAG 2.0 applies on mobile devices. They recently issued the first working draft on the topic. The guidelines and principles of WCAG are explained using the POUR method: Perceivable, Operable, Understandable, Robust.

In this post I will distill the W3C information for the Perceivable principle.

Small Screen Size

Guidelines include:

  • Use a responsive design and minimize the amount of information that is put on each page
  • Use fewer images
  • Focus on the features needed to operate in the mobile environment
  • Use a “reasonable” default size for content and touch controls to reduce the need for zooming
  • Make sure link text does not exceed the width of the device
  • Put form fields below their labels

Zoom/Magnification

The suggestions include:

  • The user should be able to zoom to 200%. Do not block this with the page’s viewport meta element.
  • Support system fonts that follow platform level user preferences for text size
  • Support options on the page to allow the user to change text size

Contrast

Mobile device content is viewed on smaller screens and in different conditions so the allowable ratio for lessened contrast on larger text on desktop devices must be considered carefully for mobile apps. Therefore, the W3C suggestion at this point is that developers should strive to apply the lessened contrast ratio only when text is roughly equivalent to 1.2 times bold or 1.5 times (120% bold or 150%) that of the default platform size. Even then, the user must be able to zoom to magnify the text.

Mobile device image: William Hook

Web Education Community Group at the W3C

A new W3C web education community group is building and forming. You can join and participate here: w3.org/community/webed.

The Web Education Community Group (CG) aims to evolve the Web and improve the overall skill set of the web industry by improving the quality of available web education resources and courses around the world.

There’s a wiki at w3.org/community/webed/wiki/Main_Page. The curriculum from WaSP InterACT is being moved there. This will increase distribution and participation in keeping the web standards based web education curriculum that InterACT created current and relevant.

I know some of you are interested in working with Move the Web Forward. As web educators, joining and participating in the Web Education Community Group at the W3C is a perfect way to contribute to moving the web forward.

HTML5 working draft on italic and bold

As a comment to  em and his buddy strong, Tony Fahnestock sent a tweet mentioning the way the elements <i> and <b> are being treated in the working draft of HTML5 in a section called “text-level semantics.”

Here’s how the <b>, or bold, element is defined there.

The b element represents a span of text to be stylistically offset from the normal prose without conveying any extra importance, such as key words in a document abstract, product names in a review, or other spans of text whose typical typographic presentation is boldened.

The following example shows a use of the b element to highlight key words without marking them up as important:

<p>The <b>frobonitor</b> and <b>barbinator</b> components are fried.</p>

In the following example, objects in a text adventure are highlighted as being special by use of the b element.

<p>You enter a small room. Your <b>sword</b> glows
brighter. A <b>rat</b> scurries past the corner wall.</p>

Another case where the b element is appropriate is in marking up the lede (or lead) sentence or paragraph. The following example shows how a BBC article about kittens adopting a rabbit as their own could be marked up:

<article>
 <h2>Kittens 'adopted' by pet rabbit</h2>
 <p><b>Six abandoned kittens have found an unexpected new
 mother figure — a pet rabbit.</b></p>
 <p>Veterinary nurse Melanie Humble took the three-week-old
 kittens to her Aberdeen home.</p>
[...]

The b element should be used as a last resort when no other element is more appropriate. In particular, headings should use the h1 to h6 elements, stress emphasis should use the em element, importance should be denoted with the strong element, and text marked or highlighted should use the mark element.

I want to emphasize this sentence: The b element should be used as a last resort when no other element is more appropriate. When semantic meanings are considered, almost any other element is probably more appropriate.

Let’s stray off topic a moment to talk about <mark>. The <b> is defined as a stylistic element that conveys no extra meaning. A new element, <mark> is suggested for highlighting text. Here’s what the working draft says about <mark>:

The mark element represents a run of text in one document marked or highlighted for reference purposes, due to its relevance in another context. When used in a quotation or other block of text referred to from the prose, it indicates a highlight that was not originally present but which has been added to bring the reader’s attention to a part of the text that might not have been considered important by the original author when the block was originally written, but which is now under previously unexpected scrutiny. When used in the main prose of a document, it indicates a part of the document that has been highlighted due to its likely relevance to the user’s current activity.

Semantically speaking, it seems to me that <mark> conveys meaning for highlighting text to a greater degree than <b>, which is used for stylistic reasons in HTML5, as it has been in HTML4 and XHTML.

Back to the <i>, or italics, element. From the working draft:

The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, a ship name, or some other prose whose typical typographic presentation is italicized.

Terms in languages different from the main text should be annotated with lang attributes (or, in XML, lang attributes in the XML namespace).

The examples below show uses of the i element:

<p>The <i>Felis silvestris catus</i> is cute.</p>
<p>The term <i>prose content</i> is defined above.</p>
<p>There is a certain <i lang="fr">je ne sais quoi</i> in the air.</p>

In the following example, a dream sequence is marked up using i elements.
<p>Raymond tried to sleep.</p>
<p><i>The ship sailed away on Thursday</i>, he dreamt. <i>The ship had many people aboard, including a beautiful princess called Carey. He watched her, day-in, day-out, hoping she would notice him, but she never did.</i></p>
<p><i>Finally one night he picked up the courage to speak with her—</i></p>
<p>Raymond woke with a start as the fire alarm rang out.</p>

Authors are encouraged to use the class attribute on the i element to identify why the element is being used, so that if the style of a particular use (e.g. dream sequences as opposed to taxonomic terms) is to be changed at a later date, the author doesn’t have to go through the entire document (or series of related documents) annotating each use. Similarly, authors are encouraged to consider whether other elements might be more applicable than the i element, for instance the em element for marking up stress emphasis, or the dfn element to mark up the defining instance of a term.

This definition of <i> offers more proper uses for the <i> element in ways that do provide limited semantic underpinnings. Use <i> to offset text from the normal prose in ways that indicate “taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, a ship name” but not as a way to highlight text (use <mark> for that) or a way to emphasize text (use <em> for that) or a way to indicate the defining instance of a word (use <dfn> for that).

With the addition of a class attribute or a lang attribute, the <i> element can be made even more semantically self-explanatory.  HTML4 and XHTML both already encourage the lang attribute when italics are used to indicate another language, so this is not new to HTML5.

Useful Links: Passwords, YUI, mobile web class

Useful links include an article about password security, a new YUI release link, a class in mobile web best practices.

The Usability of Passwords looks at ways to make passwords more secure. Worth reading.

YUI 3.x Preview Release 2. If you find the Yahoo! User Interface helpful, the new release includes Widget and Plugin infrastructures.

A W3C course in Mobile Web Best Practices is available. It takes about 2 hours a week through June and July, costs 99euros. Here’s the full course description. IMO, it would be wonderful if a large number of university instructors who are training future web professionals were able to take this course.