accessibility

Tabindex can be a very helpful attribute when coding a complexly-structured web form or page for accessibility.  It basically tells a page the order in which elements should be highlighted when the tab key is used.  Remember, lots of assistive technologies use the tab input. 

While coding, I stumbled across this little nugget that I thought I'd share here, thanks to Edward Bilodeau (same guy, new blog).

How to get Firefox/Mac to recognize tab index

I just spent the better part of an hour trying to 
get tabindex to work under Firefox/Mac OS X.  
The solution lies not in Firefox, but in the Mac 
OS X preferences.

Apple Menu > System Preferences > 
Keyboard and Mouse > Keyboard Shortcuts and 
under "Full Keyboard Access" choose "All controls".

Sweet lord....

Link to original

Without this enabled, every page in your browser becomes a keyboard trap.  Very frustrating.  Thanks, Edward!

The newly-registered #drupal-accessibility channel is open and ready for accessibility-related development discussion and conversation.  I'm setting up logging so we can possibly use it to document things like conf calls and other Drupal chats related soon.
Check it out:

• Drupal IRC channels listing
• #drupal-accessibility
• How to use IRC

Programmers have daily close contact with web accessibility standards.  They can familiarize themselves with standards and code them directly into applications and tools, know what to look for in content editing tools and management systems, and help ensure that site designs are made accessible for everyone.

In web accessibility, much emphasis is placed on making a site's content work with screen readers.  While this is a crucial step in the accessibility process, there are many other measures to take into consideration.  The way a site looks will greatly impact the user's experience.  Designers can have a large influence on a site's web accessibility as it relates to any disability, especially visual disabilities, perception disabilities, intellectual disabilities, memory impairments, and physical disabilities.

Writing content for the web is a daily task.  Websites that update content frequently are more valuable to the user, as this reflects that the owners of the site care about the quality of the information they are putting out on the web. 

Just got back from the eduWEB conference in Chicago where I presented about content accessibility standards for higher-ed websites.  More on this (and a possible screencast) later, but a couple of issues consistently arose from this and some emails and communication from others on the Drupal 7 Accessibility Task Force that I'm just putting out there.

1. Headings - how many and when? 

Basically, h1 - h6 tags can be used by many assistive technologies to help disabled users scan a page.  Some screen readers can be commanded to "read only headings."  From a semantic standpoint, they also help web content maintain context that would otherwise only be conveyed visually.  Now generally, the rule of thumb is this: one h1 heading, which must be unique OR the name of the site (if this is the homepage or it's otherwise appropriate), with subheadings filled in by h2 headings.  On rare occasions that there are sub-subheadings of content, h3 tags should be used but generally on one page, it's more common to see one big heading, a few smaller headings, and maybe one really small heading.  Anyway, the question has come up recently, is this appropriate?  In certain situations, a page will need the name of the site and a unique title for the page visible on the page.  Do we smush everything into one line then?  Or do we have two h1 headings?  That's essentially like a book with two titles.  Visually it can distract the user and from an accessibility standpoint, would certainly confuse screen readers etc.

In July 2006, I was fortunate enough to be asked to podcast several sessions at a conference I was attending.  It was just three years ago, but podcasting was still something so new and exciting in many fields of technology that it was considerably on the bleeding edge.  Today, the techniques and tools we used then would be considered rudimentary and unnecessarily old-school. 

Now the sleeker tools are available to more and more people.  And what do we have?  More than 100,000 podcasts are hosted on iTunes, and countless numbers more than that are hosted all across the web.  With quick and easy publishing tools, it's easy to create content and even easier to distribute it.  Before you know it, you can have a ton of subscribers (almost as many as you have followers on Twitter).

According to W3.org, the Mobile Web Best Practices (MWBP) Working Group and the Web Access Initiative (WAI) Education and Outreach Working Group yesterday released a final draft of "Relationship Between MWBP and WCAG."

This document is one of several new writings to come out of W3 regarding the mobile web and content accessibility standards.  As more and more mobile devices gain access to the interwebs, more standards arise. 

A gear is a component within a transmission device that transmits rotational force to another gear or device. A gear is different from a pulley in that a gear is a round wheel that has linkages ("teeth" or "cogs") that mesh with other gear teeth, allowing force to be fully transferred without slippage. Depending on their construction and arrangement, geared devices can transmit forces at different speeds, torques, or in a different direction, from the power source.

(Thanks, Wikipedia.)

Been doing some research recently regarding components of web accessibility.  For a site, a page, an app to be fully accessible, it takes cooperation in several relationships between components.