Category: WebTeacherTips

ARIA States 101

See Also: ARIA Roles 101

As part of the Web Accessibility Initiative (WAI), the Accessible Rich Internet Applications Suite (ARIA), defines a way to make Web content and Web applications more accessible. It is used to improve the accessibility of dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies.

ARIA specifies the following:

  • Roles to describe the type of widget presented, such as “menu,” “treeitem,” “slider,” and “progressmeter”
  • Roles to describe the structure of the Web page, such as headings, regions, and tables (grids)
  • Properties to describe the state widgets are in, such as “checked” for a check box, or “haspopup” for a menu.
  • Properties to define live regions of a page that are likely to get updates (such as stock quotes), as well as an interruption policy for those updates—for example, critical updates may be presented in an alert dialog box, and incidental updates occur within the page
  • Properties for drag-and-drop that describe drag sources and drop targets
  • A way to provide keyboard navigation for the Web objects and events, such as those mentioned above

This article will focus on the third item in the list relating to states. ARIA states work now in many browsers and screen readers. When they don’t, they are harmless. The use of ARIA states goes beyond basic HTML role definitions and moves into widget and web app development. Perhaps for this reason, clear information about states is less available.

The W3C definition of state.

A state is a dynamic property expressing characteristics of an object that may change in response to user action or automated processes. States do not affect the essential nature of the object, but represent data associated with the object or user interaction possibilities.

The W3C further defines how states (and properties) are related to ARIA roles, and how states and properties differ.

The terms “states” and “properties” refer to similar features. Both provide specific information about an object, and both form part of the definition of the nature of roles. . . .  states and properties are both treated as aria-prefixed markup attributes. However, they are maintained conceptually distinct to clarify subtle differences in their meaning. One major difference is that the values of properties (such as aria-labelledby) are less likely to change throughout the application life-cycle than the values of states (such as aria-checked) which may change frequently due to user interaction.

Global States

Some states are considered global, meaning they can be applied to any element regardless of whether a role is applied to the element. These states are listed, with links going to the W3C for further information on each state.

Widget States

Attributes of widgets that require user interaction that express state are the following:

Code Examples

It is hard at this point in ARIA use/adoption to find examples of ARIA states in use. If you can point me to examples, I’d like to see them. Few people outside the W3C are trying to explain ARIA states in educational articles like this one and the examples are limited. The topic needs are great deal more explaining, in my opinion.

ARIA states can be used with forms. In this example, aria-required="true" adds information about the state the object is in.  The value “true” is an example of numerous values that can be applied to ARIA states such as “number” or “string”.

<label for="firstName">First name:</label>
<input id="firstName" type="text" aria-required="true">

Here’s another:

<li role="menuitemcheckbox" aria-checked="true">Item text</li>

Resources

ARIA Roles 101

See Also: ARIA States 101

As part of the Web Accessibility Initiative (WAI), the Accessible Rich Internet Applications Suite (ARIA), defines a way to make Web content and Web applications more accessible. It is used to improve the accessibility of dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies.

ARIA roles work now in many browsers and screen readers. When they don’t, they are harmless.

ARIA specifies the following:

  • Roles to describe the type of widget presented, such as “menu,” “treeitem,” “slider,” and “progressmeter”
  • Roles to describe the structure of the Web page, such as headings, regions, and tables (grids)
  • Properties to describe the state widgets are in, such as “checked” for a check box, or “haspopup” for a menu.
  • Properties to define live regions of a page that are likely to get updates (such as stock quotes), as well as an interruption policy for those updates—for example, critical updates may be presented in an alert dialog box, and incidental updates occur within the page
  • Properties for drag-and-drop that describe drag sources and drop targets
  • A way to provide keyboard navigation for the Web objects and events, such as those mentioned above

This article will look at the first two items dealing with ARIA roles.

How to use roles

As the list mentioned, roles describe widgets and structure. Structural roles are added to markup as attributes of elements. In XHTML, for example:

<div id="header" role="banner">
<div id="nav"  role="navigation">

or in HTML5

<header role="banner">
<nav role="navigation">

Roles used in ways like the preceding examples are navigation aids for machine readers and for assistive devices such as screen readers.

Roles that describe widgets are added to markup with additional information. The role in the example below identifies the element as a slider, with additional values using the aria prefix prepended to the property name. For example, in a slider widget that allows the user to select the day of the week, the values 1 – 7 indicate the days of the week. The first day of the week, number 1, is Sunday. The aria-valuemin and aria-valuemax restrict the options in the slider to 1 – 7.

<div role="slider"
aria-valuenow="1"
aria-valuemin="1" aria-valuemax="7"
aria-valuetext="Sunday"></div>

List of roles

The W3C list of roles is quoted below. Links go to further definitions of each role on the W3C site.

Roles that act as standalone user interface widgets or as part of larger, composite widgets.

Roles that act as composite user interface widgets. These roles typically act as containers that manage other, contained widgets.

Roles that describe document structures that organize content in a page.

Roles that act as navigational landmarks

Additional Resources

Resolving conflicts in CSS made simple

Two or more conflicting CSS rules are sometimes applied to the same element. What are the rules in CSS that resolve the question of which style rule will actually be used when a page is rendered by a browser? The answer is, “it’s complicated.” Several factors are involved. I’ll give you a brief explanation of each factor.

Inheritance

Some properties are passed from parent to child. For example, this rule in a style sheet would be inherited by all child elements of the body and make every font on the page display as Georgia.

body {font-family: Georgia;}

The Cascade

Within the cascade, more than one factor can figure into determining which one of several conflicting CSS rules will actually be applied. These factors are source order, specificity and importance. Location is part of the cascade, too.

Source order means the order in which rules appear in the style sheet. A rule that appears later in the source order will generally overrule an earlier rule. Consider this example.

body {font-family: Georgia;}
h1, h2, h3 {font-family: Arial;}

Because the h1, h2, and h3 selectors are in the source order after the body rule, the headings would display in Arial, not in Georgia. There’s also the fact that the selector is picking specific elements.

Specificity

Specificity is determined by a mathematical formula, but common sense can help you understand it.

p {font-family: Georgia;}
.feature  p {font-family: Arial;}

In this case, the selector .feature p is more specific than the selector p. For any paragraph assigned to the class ‘feature’ the font-family would be Arial. Common sense tells you that selecting a paragraph that belongs to a particular class is a more specific choice than selecting all paragraphs. The more specific selector overrules the less specific selector.

!important

There are rules that are declared !important. !important rules always overrule other rules, no matter what inheritance, source order or specificity might otherwise do. A user created stylesheet can use !important to overrule the author’s CSS.

*{font-family: Arial !important;}

This rule would mean that everything (* selects everything) would be Arial no matter what other rules were used in the CSS.

Location

Style rules can exist in a number of locations in relation to the HTML page affected. The location of a rule also plays into determining which rule actually ends up being implemented. The locations are:

  1. Browser style rules
  2. External style rules
  3. Internal style (in the document head) rules
  4. Inline style rules
  5. Individual user style rules

In the list, the browser style rules are the most “distant” from the HTML page, the individual user styles are the “closest.” Within this cascade of style declarations, the closest rule wins. An inline style overrules an external style, which overrules a browser style.

Related posts:

HTML5: the new hgroup element

In HTML5, the new hgroup element serves an interesting purpose. I want to build you an example, starting with the hgroup element and working outwards to show how it could be part of the new article element.

The hgroup element can contain only h1-h6 elements. Here’s an example:

<hgroup>
<h1>10 Terrific Tech Blogs by Women</h1>
<h2>Code, Gadgets, Issues, and Science</h2>
</hgroup>

It isn’t necessary to use an h1/h2 combination. It could be an h2/h3 or h3/h4. It depends on where you’re putting it.  The defining attribute of hgroup elements is that the first heading element is what goes into the document outline. The secondary heading is not part of the outline. The secondary headings in the hgroup are meant for taglines, subheads, and other lesser text that relates to the main heading in the hgroup.

HTML5 contains a new header element. The hgroup element can be nested in a header element, like this.

<header>
<hgroup>
<h1>10 Terrific Tech Blogs by Women</h1>
<h2>Code, Gadgets, Issues, and Science</h2>
</hgroup>
</header>

Keep in mind that the header element can contain other elements such as a nav or a figure, although I don’t have them in the example.

As we keep working outwards from the headings, we can imagine that the header element is part of an article element. That might look like this:

<article>
<header>
<hgroup>
<h1>10 Terrific Tech Blogs by Women</h1>
<h2>Code, Gadgets, Issues, and Science</h2>
</hgroup>
</header>
<p>Tech tips, geeky how-tos, thoughtful analysis of issues, news about the latest gadgets, ideas for improving your blog—you’ll find it all in these 10 terrific tech and science blogs. They just happen to be written by women.</p>
<p>more content</p>
</article>

The article element can also contain a new element called footer. The article footer would contain material relevant to the article—perhaps a date, an author’s URL, or other material.

<article>
<header>
<hgroup>
<h1>10 Terrific Tech Blogs by Women</h1>
<h2>Code, Gadgets, Issues, and Science</h2>
</hgroup>
</header>
<p>Tech tips, geeky how-tos, thoughtful analysis of issues, news about the latest gadgets, ideas for improving your blog—you’ll find it all in these 10 terrific tech and science blogs. They just happen to be written by women.</p>
<p>more content</p>
<footer>
<p>Some footer content</p>
</footer>
</article>

The now complete article represents a stand-alone piece of content.  It has a heading and content and can be lifted of-a-piece to be placed elsewhere or syndicated some way. In a document outline, it would appear with all the content outlined under the top level heading in the hgroup element.

3 Tools to Check Color Contrast

Color contrast is a major accessibility issue on a web page. The greater the amount of contrast, the better the readability is for a page. The most contrast you can get is black text on a white background. Things go downhill from there. The degree of readability loss with colors other than black and white can be determined by a mathematical formula.

Three of the best tools for checking color contrast are:

Each of the tools will report back to you with a score for your page’s contrast. If your colors don’t have enough contrast for readability, you’ll get the bad news quickly with one of these tools.

7 Tips for New Bloggers

I’ve been blogging a long time–since 2001. People ask me about starting blogs all the time. Here’s what I usually tell them.

  1. It’s easy to start a blog. If you can use Word, you can blog.
  2. It’s better if you are comfortable with web sites, icons, the Internet, and your computer isn’t scary to you.
  3. It’s better if you know the basics of HTML and CSS and understand images. However, if you’re a musician or an artist and don’t want to think about those things, you can still have a blog.
  4. You need to be sure you have something to say and are burning to say it. You need a reason to keep coming back week after week to produce new material. It doesn’t matter what your thing is, but you need to have a passion for writing about it.
  5. You have to commit to it. It takes constant time, effort, and work. If you don’t have the self-discipline to make a long-term commitment to a writing project, don’t do it.
  6. You need to be a decent writer. You need to enjoy writing. You don’t have to be a literary genius. But you need to be willing to spell check, grammar check, proofread, edit, refine, rewrite, and make an effort to write well. Within that restriction, be yourself. Use your own voice, your own tone, your own style.
  7. Don’t expect a miracle. There are millions of blogs but only a few people are famous bloggers who make a living from a blog. Do it because you want to say something, not because you want to get something.