Addy Osmani has lots of good JavaScript and JQuery help on his blog.
In case you didn’t know yet which social network is conquering the world, here’s an infographic from Vinco’s Blog.
Category: JavaScript
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 asaria-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.
alertalertdialogbuttoncheckboxdialoggridcelllinklogmarqueemenuitemmenuitemcheckboxmenuitemradiooptionprogressbarradioscrollbarsliderspinbuttonstatustabtabpaneltextboxtimertooltiptreeitem
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.
articlecolumnheaderdefinitiondirectorydocumentgroupheadingimglistlistitemmathnotepresentationregionrowrowheaderseparatortoolbar
Roles that act as navigational landmarks
Additional Resources
Useful Links: SVG, BAM, InterACT
Doug Shepers from the W3C put together a slideshow in SVG, HTML, CSS and JavaScript that is worth your time. It’s an SVG demo. Play with it. View it in the latest Firefox.
BAM or Blog Accessibility Mastermind is a six lesson course offered by Glenda Watson Hyatt of Do It Myself Blog. I haven’t looked inside the course, but I suspect it’s a good one.
Based on the interest and number of questions Derek Featherstone got during his accessibility presentation at the recent InterACT Summit, I’d say interest from educators about accessibility is very high right now. There’s a free online course from the Web Standards Project (WaSP) InterACT curriculum about accessibility. The course is a perfect resource for teachers. It’s a stand alone course. If you are teaching with InterACT with Web Standards and its chapters on accessibility, the online material a great time saver. Online materials such as exam questions, grading matrices, assignments, objectives, and resources go hand in hand with the material in the book.
Review: Web Design for Developers
A review by Web Teacher of Web Design for Developers: A Programmer’s Guide to Design Tools and Techniques (Pragmatic Programmers)
(rating: stars)
Web Design for Developers: A Programmers Guide to Design Tools and Techniques by Brian P. Hogan, is, as the title suggests, aimed at developers rather than at designers. In just over 300 pages, Hogan tries to cover everything about creating a web site starting from initial pencil sketches to the finished product. Included are chapters about color, typography, structure, content, HTML, CSS, print and mobile CSS, cross-browser isssues, accessibility, search engine optimization, testing and a set of resources.
The list of topics sounds really good. It’s a lot to ask of one book, and it’s a decent book, but it isn’t a great book. The 300 pages are a restriction. Some things that could take a whole chapter to explain were mentioned with one or two sentences. There are good tips and techniques in the book, but there are also a number of things about the book that I found problematic. For example, in the section on building the home page search form with HTML, the notion of using the <label> with form fields is ignored. Later in the book, the developer is told to go back to the form and add <label> elements for the sake of accessibility. I’m glad he got around to mentioning it, points for that, but doesn’t it make better sense to tell a developer how to design an accessible form right the first time it’s mentioned? Otherwise, it feels like something you might do after you’re finished if you feel like getting around to it.
Some of the information seems out of date. The accessibility chapter talks about using access keys, an idea that’s no longer considered best practice. The use of unobtrusive JavaScript is mentioned in passing after several JavaScript ideas that are not unobtrusive have been trotted out. A tag cloud example is given with links reading <a href="#">. The use of the pound sign in the element is explained by saying that it will be replaced programmatically later, but that programming is never mentioned.
The sections on color and typography were good. The sections on images and image optimization were good.The coding examples in both HTML 4 and HTML 5 for the layout were well done. I had to keep reminding myself that the audience for this book is developers who are adept at things like Java or Ruby or PHP but don’t necessarily know how to make a web site look appealing. Limited and flawed as the book seems to a web standards advocate like myself, to a developer this might be the quick and simple guidance that is needed for a project.
When I read the title of the book I initially thought it might be something along the lines of the classic The Non-Designer’s Web Book
Summary: A general and wide-ranging look at web design techniques.
Technorati Tags: Web Design for Developers, book reviews
Review: Fancy Form Design
A review by Web Teacher of
(rating: stars)
Fancy Form Design by Jina Bolton, Tim Connell and Derek Featherstone is from Sitepoint Book (2009). This is really an excellent little book. It gives you tips on planning and designing a form that is both attractive and usable. It provides information on structuring the form using standards-based HTML. Both usability and accessibility features are built into the form structure as a matter of practice in this book. You’d hardly expect less with authors of the caliber of the three who worked on the book.
Since this book is just about one thing, forms, you learn some things you might not learn in a book that treated forms as a small part of a larger whole. For example, there is an interesting discussion about when to use legends with fieldsets, and when you’d be better off not using legends. You learn about the types of error messages that are most useful in form design. The fine points of labels are discussed.
In the chapter on styling the form with CSS, there are some excellent tips for form design. Everything from ideas for styling with icons, sprites, and styling widgets is included in the CSS chapter.
The final chapter takes you through some JavaScript enhancements that will improve your form without making it inaccessible.
The book reads fast, the code examples are right there and are clearly explained.
Summary: A must-have book for the form designer.
Technorati Tags: Fancy Form Design, book reviews
Codeburner Add-on for Firefox
You now have access to all the Sitepoint References for HTML, CSS, and JavaScript available in Firefox as an add-on. You can download the Codeburner add-on free from Sitepoint.
The references provide syntax information, browser compatibility charts and sample code for HTML and CSS.
The new add-on was just released. For a limited time, you can get a free book as a bonus when you download it. The book is Build Your Own Firefox Add-on.
If you are a Firebug user, you may realize that these same reference materials were available as a part of Firebug. The new add-on eliminates the Firebug step and gives you quick access to the reference materials at the bottom of the Firefox page.
It’s a simple toggle open and shut to see the reference panels. When you install it, a Codeburner icon will appear on your status bar. Just click the icon to open up the references. You see it here on my status bar with the pointing finger indicating which icon it is.
When you initially open it, you may have to futz with the drag handles a bit to get all three windows to show up and sized the way you want.
In the left window you can search for an HTML element, HTML attribute, or CSS property. As soon as you start typing in the search box, you see results on the right. I typed “padd” before I stopped typing, and got a number of results involving the word padding. In the center window, you see information about browser compatibility, standards-compliance, and a brief summary of usage. If you don’t find out what you needed to know, there’s a link to the SitePoint References online. The window on the right gives you a generic example of the element, attribute or property you searched for in use. The window on the right will display information for which ever of the numerous items in the center window you select.
You can learn about the elements and properties based on the page you are on. Select the DOM option in the left window, navigate through the DOM tree to find whatever you are interested in, and select it. I selected a <p> element in the image above.
If the code example in the right window is not enough information for you, you can click the “More information online” link to see a live demo. (The same function is available as an option in the contextual menu you see when you right-click on at item in the search results window in the center.)
Don’t want half your browser space taken up by the Codeburner pane? You can detach it into a separate window with a click on a small up arrow near the X that would close it completely.
The reference material available with the Codeburner add-on is already available from Sitepoint, in books, and was part of the Firebug add-on. The new add-on is a convenience. It can give you quick information without a lot of effort. If you are at that stage in your learning curve where you still spend a lot of time looking things up, you’ll love this one.