Katherine Lynch.org

So, mobile stylesheets are not the Holy Grail of mobile web development that they once were, but they do still come in handy.  Rather than attempting to recognize the technology or the OS specifically, it's easier now to go by device width.  I used this technology in order to have a "switch to mobile version" toggle in the footer of the full browser version of a site, but only on mobile devices:

<link rel="stylesheet" href="handheld.css" type="text/css" />
<meta name="viewport" content="width=device-width" type="text/css" />
<link rel="stylesheet" href="override-handheld.css" type="text/css" />
<link rel="stylesheet" media="all and (max-device-width: 480px)" href="handheld.css" type="text/css" />
<link rel="stylesheet" media="all and (min-device-width: 481px)" href="handheld.css" type="text/css" />
<link rel="stylesheet" media="all and (min-device-width: 1024px)" href="override-handheld.css" type="text/css" />

Let me expand this a little.  In "handheld.css," we have the following:

#footer-switch{
    display: block;
}

This allows the toggle switch in the footer of the full browser version to be displayed.  In "override-handheld.css," we have, not surprisingly:

#footer-switch{
    display: none;
}

This is, obviously, meant to hide the toggle.  Please note, this CSS will actually remove the toggle entirely from the browser, not just visually, but for all hardware including screenreaders, as if it doesn't exist.  This is our goal though, as we only want to call "override-handheld.css" when this particular navigational element should not exist.  

So, in the first line, we call the "show" CSS.  We do this as a "just in case," should all of our conditionals fail for an edge-case mobile user, the switch is available.

This little line - 

<meta name="viewport" content="width=device-width" />

is used to help ID the device width, and is mostly needed to make Android 2.2 and beyond play nicely with mobile stylesheets.  Without this, Android devices running 2.2 and above will simply ignore these media queries. 

Now, these last three -

<link rel="stylesheet" media="all and (max-device-width: 480px)" href="handheld.css" type="text/css" />
<link rel="stylesheet" media="all and (min-device-width: 481px)" href="handheld.css" type="text/css" />
<link rel="stylesheet" media="all and (min-device-width: 1024px)" href="override-handheld.css" type="text/css" />

work for all other mobile devices.  Most devices will be served by the first line, as many handhelds still have a width of 480px or less.  The second line is for (again) many newer Androids, some Blackberries, and of course, tablet devices (*cough iPad cough*).  The last line of CSS is only called for desktop devices, and this hides the mobile toggle switch.  Win!

And speaking of iPads, if your mobile optimized site needs some love especially for the iPad or tablet devices, you can use this same technique in your mobile site's CSS.  Just throw this into the header -

<link rel="stylesheet" media="all and (min-device-width: 481px)" href="tablet.css"> 

and put your tablet-optimized CSS into the appropriate file.  Yay, many conditions!

So Lullabot has these awesome podcasts that they do with various awesome people in the world of Drupal development.  When I was at DrupalCon San Francisco last month, I was interviewed about my accessibility presentation and my work at Drexel for one.  Here it is:

• Drupal Voices 99: Katherine Lynch on Accessibility Tips for Websites

Some other really cool podcast interviews from DCSF that I highly recommend:

• Everett Zufelt on Accessibility in Drupal
• Jenn Simmons on Usability, CSS3, and Getting Bartik into D7
• Dries Buytaert on the State of Drupal 2010
  
• And my personal favorite, Jack Aponte on Diversity, Power and Privilege in Open Source Communities

Enjoy!

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.

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.