Technology Writings

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!

I presented this 1-hour session at DrupalCon San Francisco on April 19, 2010.

Abstract:

As technology advances, it is more important than ever to code with web accessibility in mind. Web accessibility measures help users with disabilities related to limitations of vision, hearing, learning, cognition, and motor skills to use the web effectively.

So you know how Wordpress comes with that slick little TinyMCE-based rich text editor built in when you install?  A lot of clients like that, particularly those who do not know any HTML.  The fact that Drupal 6 does not ship with a rich text editor installed in the back end frightens some users, with that big empty "Body:" box and not a single tool to be found.  But they shouldn't be afraid, as there are plenty (PLENTY) of ways to create content for Drupal sites without knowing so much as a tag of HTML.  For this article, we'll focus on rich text editors for the body, particularly FCKEditor.

FCKEditor has been popular for years, and just a few months ago was replaced with CKEditor (a supposedly less suggestive name).  I like CKEditor a lot so far.  It claims full accessibility support as an editing tool (though notably, it claims standards compliance with Section 508 and WCAG 1.0, not 2.0).  I can't verify 100% but I can say that, from what I have tested, it is so far, so accessible.  I liked FCKEditor over TinyMCE for the last few years because it inherently encouraged accessible markup a bit more than TinyMCE.  For instance, data table scoping was way easier in general, with FCKEditor.  Other things like headers and lists came at least as naturally as with any other editor.  

I've had a fair number of Drupal 6 clients who like FCKEditor and want to keep it installed for the time being, so I generally use the actual Drupal FCKEditor module for the job, for the reasons outlined above, plus client preference.  It should be noted, however, that a completely stable release of the Drupal CKEditor module is available now and is continuing to be updated/improved for Drupal 6.  Give it a try, you'll like it! (Hey Mikey!)

Now one thing that end user admins tend to want is an ability, similar to that within Wordpress, to upload local images into their content.  With Wordpress's built-in media library, the user clicks the little "add an image to your media library" icon, browses their local files and selects what they want, uploads it, fills out the information, and boom, image-riddled blog post.  It's quite easy to replicate this accepted workflow in Drupal 6.  And here it is:

I attended and spoke at the Assistive Technology Industry Association (ATIA Chicago) conference last month.  The conference was focused on educating attendees about assistive technologies and their uses in the world today.  Another particular focus of the conference was creating information that remains usable and accessible by users with assistive technologies.  I attended several sessions and spent a good deal of time discussing on the exhibition floor.  Here are some of the highlights.

In Wordpress, it's always been easy to throw a search box into your blog's theme that searches across your blog:

<form id="searchform" method="get" action="<?php bloginfo('home'); ?>">
<input type="text" name="s" id="s" size="15" />
<input type="submit" value="<?php _e('Search'); ?>" />
</form> 

It used to be the case that the search function would harvest all of the information--tags, categories, content--of posts, but only of posts.  In other words, pages were excludable from the search.  However, as more users take on Wordpress for more projects, pages have begun to get used in more ways, an so the fine people at Wordpress went ahead and included pages in the site search functionality.  So in Wordpress 2.8, if you conduct a search, you get page entries too.

There are some good plugins out there to limit searching, but a generally easy and foolproof way to manipulate search in Wordpress 2.8 is to do this.

Create a search results template in your theme by creating a file called search.php.

In search.php, you'd generally have something like this:

<?php if (have_posts()) : ?>

<h2>Search Results</h2>
<?php while (have_posts()) : the_post(); ?>
<?php /* your post formatting code in here */ ?>
<?php endwhile; ?>
<?php else : ?>
<h2>No posts found. Try a different search?</h2>
<?php endif; ?>

What’s the deal with Flash on the iPhone?  There have been many reports that a lack of Flash support for the iPhone will continue.  This is despite the fact that more mobile devices including Blackberry, Palm, and even Google Android (custom installs with wide support coming next year), are building up support for the web technology.  Whether you love Flash sites or hate them, Flash is a prevalent technology, meaning that users require some sort of support on popular user agents, and if no support, then a good explanation for its absence.

According to Adobe, the developers of Flash have been attempting for over a year to work with Apple to get Flash loadable on iPhones, but are not getting the support from Apple that they need.  And why not?  According to an article from PC World Magazine, speculation includes two main reasons now.  One, a lack of support for Flash on iPhones based on their one-app-at-a-time functionality, which could make users unable to access other features in Safari or other web browsers on the iPhone.  And two, far more likely also, is Apple’s heavy involvement with the development of HTML 5, which promises to make plugin applications a thing of the past, ultimately.  They’re already testing HTML 5 in browsers.  It is important to note that Apple has not come out and said there will be no Flash support on the iPhone, but chances are, it’s going to take a long time if it comes at all.

So Adobe has come up with a solution.  In an effort to keep Flash relevant, usable, and adaptable on the Internet, according to an article in yesterday’s Computer World, an announcement was made at the Adobe Max conference that Adobe Systems has developed a workaround for Flash developers who want to work with the iPhone.  It will not be able to run in the Safari browser due to Apple’s license terms, and will not be able to compile runtime code.  It will, however, allow Flash developers to compile things written for other mobile devices, and reinterpret them as standalone applications for the iPhone.

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.