I am drafting an article for the RI:Technology blog on Screen readers and Search Engines, and was reviewing a paper a colleague wrote about Search. He mentioned sIFR as a technique “to bring content to search engines”. I asked another colleague about this, as I’d always just considered sIFR as a “stylability” technique.
We started talking about the weight factor of search engines, whether content written to a page and then sIFRized would be weighted more heavily than the alt text of an image. I hadn’t really thought about that before. I then mentioned a habit I have of placing images within a heading tag, i.e.
<h1><img alt="descriptive text" /></h1>. Toby asked if this really worked, if the alt text would be considered the header. I realized that I’d never really verified it before.

So I took a quick look at an example using FANGS, and learned that alternate text, really isn’t. Turning off images would cause the alt text to display as the appropriate heading level, but at least for FANGS, the alt text does not get surfaced as the heading (the text should show up before the colon in the screen shot below)

Now, obviously FANGS is an emulator, and it’s possible that a screen reader would access that alt text. But this gave me something to consider..

Today I was back in ATG developer training - in their Commerce course. Some of our time was spent looking at templates for category and product pages. This was something I’d been thinking of on my own, and it was good to see that my ideas were right on track.

Basically I had been thinking about templates on both the presentational as well as the content levels. The templates we looked at today were set at the content levels. That is, a particular template could be created to ensure consistency across pages, but there could be rules set up to support deviations from the standard. Elements are associated with a particular template, which would basically serve as the way to retrieve the specific properties of the element.

My second thought was to create a presentational template as well, to support how these elements should be displayed. A simple idea I gave a colleague would be that every product page would contain a description, a title and an image, but in some cases we may want the image to the left rather than the right. The underlying data would be the same, but we would want the presentation to be slightly different. (this could be applied even so simply as including a specific stylesheet)

Lately at work I’ve been helping out with some light Scotts work. The Scotts Miracle-Gro Company is a huge client, with several different microsites and campaigns. The recent redesign of scotts.com (disclaimer: I only performed perfunctory copy changes for the redesign) reminded me of much of the work I did at LexisNexis: scotts.com was the equivalent of a flagship product like lexis.com or nexis.com. The challenge from a branding perspective is how to maintain a consistent look and feel for subsidiaries, while still allowing them to maintain their own identity. I’ve donned both a developer’s and a business analyst’s hat in looking at these projects, and it’s a good exercise to identify the opportunities for consistency as well as for variation. This was truly where we were going with our common UX initiatives at LexisNexis before I left. How do we enhance the usability of all the sites by introducing consistent functionality, while ensuring each site meets its specific target audience’s needs?

Before I left LexisNexis, I was the UX representative on the architectural advisory board and I sat on the brand spirit (branding and identity) committee. There, we had three flagships and literally hundreds of projects a year that had some level of association with at least one of the three. It was absolutely imperative that design or development decisions were not made in isolation. The User Experience department I was a part of held design reviews every week to push for consistent user interaction and design across our products.

Coming to Resource late last June, I was thrown into agency life. It’s quite different dealing with different clients, who are paying for the development of their own unique brand and user experience. While there are always benefits in developing code libraries of common components that can be reused, the nature of the challenges we dealt with in a huge beast of an application like lexis or nexis simply don’t compare.

It’s actually fun for me to look at Scotts and see those patterns and consistent elements. In developing one microsite, I’m stretching my “build for the future” muscles again in anticipating potential future additions. It’s interesting how I can build this into my work both as a developer (coding in anticipation of reuse), and as a business analyst (explicitly identifying requirements that have shown up elsewhere or may be of significance moving forward). At LexisNexis, some of these considerations (as well as others) would be made by the system architect or a portfolio manager, but those are roles we don’t particularly have at Resource, due to the nature of most of our client engagements.

It’s interesting that considerations into the creation of a robust, usable, expandable site occur throughout the design and development process. I guess I consider it the difference between creating a web site, or developing the architecture for a web application. You can make a web site to achieve a specific purpose, or you can create a framework that supports as-yet-unknown functionality.

This is why I once felt I wanted to get into architecture: rather than putting square pegs in square holes, I want to consider the fact that I may not know what pegs I’ll be given down the road. I hope that in the movement to BA or IA, I will also be able to anticipate these unknowns and ensure we continue to deliver engaging user experiences that are also robust, usable and extensible.

As mentioned previously, I have been doing some simple email templates for our project. While we were in development, we could only send emails locally, so I was able to ensure outlook handled them properly. When we opened it up to web clients, however, we encountered several “idiosyncracies” we had to account for.

As I mentioned in my last post, I wanted to set the appropriate DOCTYPE. Yes, an admirable idea, but I completely ignored the fact that these emails were being rendered within an HTML page — hence, my DOCTYPE and html wrapper tags were stripped out. There went my doctype, along with my good old-fashioned attribute specifications for bgcolor, alink, vlink and text. So it was back to manually specifying stylistic information on every element (on the whole I’d done this already, it was the bgcolor for the entire email that was missed out on, so I had to add it to a table that was specified at 100% width and height.).

I also encountered some fun with these “smart” webclients trying to interpret the text. We have the typical disclaimer at the top of the page, “to continue to receive emails, please add XXX@mydomain.com to your address book”. Both yahoo and gmail tried to make links of things we didn’t intend, mucking with the overall look of the email. So now I am having to go back and change periods into . and at symbols into @.

Not that any of these are difficult tasks, but they were small stumbling blocks, so I wanted to be sure to capture them for next time–

Evidently you can handle all of MVC within flex, but I am still seeing it primarily as the presentation layer — perhaps as my familiarity increases, I will be more comfortable letting it handle more. in the meantime, however, it is easier for me to see flex as a way to present data — and only parts of it.

I plan to use SWFObject to include flex components within a larger page — and that also lets me add the content directly to the page, to be swapped out by the richer component if it is supported. That seems to be a decent solution for search as well as acessibility. Perhaps mobile as well?

Now, I have never been a fan of alternate presentation based on user agents, etc (browser sniffing, etc). Build to standards for a more robust, consistent solution. Otherwise there are more maintenance and consistency concerns (not to mention the fact that you can offend users by offering them up ‘dumbed down’ content). That being said, I do like the idea of progressive enhancement- which is how I am choosing to see this. I don’t want to deprive users of important information, but I do want to offer the best user experience to those who can support it.

What I’d like to figure out is how to ensure the same content is being served up, regardless of the presentational format. So if we’re feeding XML into the flex component, I want the same content written to the page. I did some quick prototype work using XSLT at LN, I’d like to investigate building modules not simply of flex, but of the entire package: XML (data), being rendered on the HTML page and supplemented as possible in a richer format.

I was recently asked how I approached coding, in terms of validation and standards. I said that when I had complete control over the code, I coded to xhtml1.0 strict. “for all browsers?” I was asked. The question took me aback. Yes, of course for all browsers. I wouldn’t even know how to code differently for separate browsers. Sure, CSS and JS take some work to standardize, but for me, coding to xhtml1.0 strict is a no-brainer. [I did give the disclaimer that when using an imposed infrastructure, I had to take a step back down to HTML4-.10 transitional for when we were using struts, and I'm still not sure we'd validate]

Further in the conversation I realized that while I can strongly claim adherence to xhtml1.0, I can’t do the same for a certain version of CSS or javascript. I know there has recently been a call for CSS2.2, but honestly, I just use code that works. So too for javascript. In a similar case, I skimmed something that mentioned some new functionality for javascript1.6. Are we up to 1.6? Who knew?

That’s what struck me: the aspect that I consider ’stable’ (xhtml), I code to completely and I’m familiar with it. The other two, that require more knowledge of ‘what works’ and ‘what doesn’t', I have more applied knowledge. I don’t know if it is due to the age of the technologies and how well they are handled by user agents or not. That is, (x)HTML is a markup language, and is platform- and device-independent. It is when you get into presentation and behaviour that the browser quirks rear their ugly heads, so it is not simply a matter of knowing the technology, but also how it interacts with the various platforms.

Will I ever get to a point where I can say “I code to CSS3?” I’m not sure..

One of our Human Factors Engineers just asked us to compile a list of “what makes good code”. He had a few initial suggestions, and they were added to for the following list. Although I think we are aware of certain principles, how do we create a checklist of what is “good” versus “poor”.

1. The code is valid
2. Inline comments are used consistently and effectively
3. Alignment and structure of the code display allows for easy scanning and reading
4. The code is accessible
5. Tables are not used for layout
6. CSS is used appropriately via an imported style sheet, a linked style sheet, or styles in the header (in that order).
7. The code is as slim and compact as possible
8. The code uses semantic markup
9. Inline styling and scripting is kept to a minimum
10. Graceful degradation is kept in mind

“The idea of accessibility of web-based technology is based on far more than the implementation of standards and technological solutions. It embodies the idea that everyone has the right to information and that everyone has the right to be included in society, regardless of disability, geographical location, langauge barriers, or any other factor”. (Introduction)

Chapter 1: Understanding Web Accessibility
“Accessibility is about designing so that more people can use your web site efectively in more situations.” (p. 13)
–Functional limitations pertain to disabilities (visual, auditory, physical, cognitive (including language and learning disabilities)
–Situational limitations relate to the prevailing circumstances (mobile devices, not having a mouse)
Most legal requirements relate to functional limitations.
Between 15 - 30% of the general population of functional limitations that can affect their ability to use technology products. That represents an estimated 50 million people in the US alone, and over 750 million worldwide.

Chapter 2: Overview of Law and Guidelines
WCAG: World Wide Web Consortium Web Content Accessibility Guidelines 1.0 = stable international specification released in May 1999.
Section 508 of the Rehabilitation Act Amendments of 1998, went into effect June 21, 2001.
WAI (Web Accessibility Initiative) launched by W3Cin April 1997 to “promote and achieve Web functionality for people with disabilities”

WCAG Priorities:
Priority 1: a web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in this document. SAtisfying this checkpoint is a basic requirement for some groups to be able to use web documents.
Priority 2: A web content developer should satisfy this checkpoint. Otherwise, one or more groups will find it difficult to access information in the document. Satisgying this checkpoint will remove significant barriers to accessing web documents.
Priorit 3: A web content developer may address this checkppint. Otherwise, one or more groups will find it somewhat difficult to access information in the document. Satisfying this checkpointwil improve access to web documents.

The majority of Section 508 rules are based on Priority 1, but there additional rules particular to US law.
“Section 508 requires Federal agencies to give disabled employees and members of the public access to information that is comparable to the access available to others.” (p 51)

Chapter 3: Assistive Technology Browsers and Accessibility
Screen readers do not actually read the screen; newer versions use the DOM to determine how to present the information
Common screen readers: JAWS, Window-Eyes
Voice Browser: IBM Home Page Reader
Text Browser: Lynx

Chapter 4: Creating Accessible Content
“The subject of accessibility on the web can be divided into three main categories: accessible web content, accessible navigation, and accessible interaction.”

Text equivalents:
–probably the most important accessibility issue, providing text informationfor web content that is non-textual. Includes images, image maps, image buttons and MM files.

WCAG: 1.1 Provide a text equivalent for every non-text element (for example, via “alt”, “longdesc” or in element content) This includes…
Section 508 1194.22(a) 1.1 Provide a text equivalent for every non-text element (for example, via “alt”, “longdesc” or in element content)

Style of alt text: Book advocates shorter alt text than even the text in an image. A sighted person can edit out “visual noise” but someone listening to the page cannot. e.g. The University of Arizona — alt=”U of A”, Also tends to avoid the words “home page” as that should be evident

Spacer gifs should always have null alt text, that is alt=”"
There is some disagreement on the alt text of stylistic elements, bullets or divider lines. The author advocates (and I agree) using null alt text. These are presentational elements and do not need to be shared with a non-sighted viewer.

There are two mechnisms for providing textual equivalents for non-text content like charts and graphs. The first is the longdesc attibute of an image. The value of the longdesc (long description) attribute is a UI, a reference to another page or a file that contains a detailled description of the content of the image, which ,ust be maintained as data changes. The problem with the longdesc attribute is that it is not widely supported by assistive technology. As a result, an alternative convention is suggestion, using the D-LINK. The D-link is a link to a file o page which is the same as the longdesc value.

<a href=”chart22.gif” width=”455″ height=”325″ alt=”Food sales for 2000″ longdesc=”sales2000.htm”><a href=”sales2000.htm”>D</a>

-Every image, image map area and image button should have a valid alt attribute.
- All images which are not active and do not convey information or are redundant should have alt=”", that is, null alt text.

Transcripts of audio:
If audio is decoration, thee is no need to add text equivalents. When the audio contains spoken words, when it is in fact the message, a textual transcript is required.

Avoiding Use of Color to Convey Information
It is estimated that 1 in 20 visitors to your site will have some for of color visio deficiency. The key is no to use color alone.

Section 508: 1194.22(c) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.

WCAG: 2.1 Ensure that all information conveyed with colo is also available without color, for example from context or markup.

Creating Accessible Tables
SCreen readers deal with tables differently now than they have in the past. Now, they read the entire contents of a cell when it is encountered, working from top left to top right, then proceeding down to the next row.

WAI 5.3: Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version)

Data Tables
Section 508: 194.22(g) Row and column headers shall be identified for data tables.
WCAG 5.1: For data tables, identiy row and column headers.

Using the <th> element and scope attribute
<th> is used to enclose data in a table that is intended to be a heading.
The scope attribute offers an alternative to the th element for specifying header informationin an HTML table.

WCAG: 5.2 For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells (Priority 1)

Section 508: 1194.22(g) Markup shall be used to associate data cells and header cells for data labels that have two or more logical levels of row or column headers.

Avoiding flicker
7.2 Until user agents allow users to control flickering, avoid causing the screen to flicker.

Summary:
–Avoid duplicate adjacent links. if both an image and text are links on the same href, enclose them both in the same anchor tag, and then place alt=”" on the image. Unside a BUTTON element put non-null alt text on any image to the extent that the information conveyed by the image is not redundant.

Chapter 5: Accessible Navigation
Major topics:
1. skip links
2. accessible frames
3. accessible image maps
4. how layout can affect navigation
5. accessible links

Guidelines for Skipping Navigation
Section 508: 1194.22(o) A method shall be provided that permits users to skip repetitive navigation.

Three methods to provide skip navigation include:
- placing the link in normal text
- creating a link as alt text on an image that doesn’t carry information
- using a text link with the same foreground and background colors
(one example of skip nav is taken from LDC!)