Katherine Lynch dot org
Blog
contact
resume
decorative icon of a mug saying 'i heart design'

"People ignore design that ignores people." - Frank Chimero

Follow me on Twitter, handle @katelynch Subscribe via RSS

accessibility

DrupalCamp Chicago slides posted


My presentation materials for "Theming Views" and "Thich, Rich, and Accessible" (accessible rich media) presentations from DrupalCamp Chicago, June 2010, are available here:

See my Presentations and Posters section for the full listing of my presentations.

My Drupal Voices interview, and some other recommendations


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:

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

Enjoy!

Drupalcon Presentation slides


Wrapping up a great, productive DrupalCon San Francisco 2010!  I've created a page with slides and video for my accessibility presentation here:

Libraries presentation slides/materials to come. <smiley>

Tabindex on the Mac


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!

#drupal-accessibility on IRC


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:

Accessibility Tips for Programmers


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.

Accessibility Tips for Designers


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.

Accessibility Tips for Content Writers


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. 

Headers and hidden content


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.

Accessible Podcasts and Vodcasts


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).