Technology Writings

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.

According to news released on the official Google Blog this morning, Google Apps is finally, truly out of beta.  This includes Google Calendar, Docs, GTalk, and of course GMail.  The "beta" is being removed from all logos today and the party hats are going on.

The Google folks aren't resting on their laurels for long though.  According to an addition Google Enterprise Blog entry, Google's efforts to be adopted by small to middling business companies will be strengthened in the coming weeks, with additional enterprise features for Premier accounts, such as email delegation (send or filter emails on behalf of another person) and email retention (so that IT admins can determine when a corporate email should be purged) currently in serious beta, to be rolled out soon.

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.