As a previously scheduled post on accessibility and indexability went live, a few folks pointed me to some news on searchable/indexable swfs.

A few of the articles I checked out:

1. Google Now Crawling and Indexing Flash Content
2. Improved Flash Indexing (Official Google Webmaster Central Blog)
3. SWF searchability FAQ

I will admit I referred to the articles with a critical eye; google has been flirting with retrieving some amount of content from .swfs for quite awhile. Yet for the first time, I got a sense there has been real progress.

The premise is that Google and Yahoo! spiders will access the content via an enhanced Flash player. This enhanced player will give the search engine spiders the ability to navigate within the Flash experience, and access and index associated resources.

This is an exciting prospect, as until now many site designers were resigned to duplicating the content that was available from within Flash on the HTML page wrapper that housed the Flash. This followed the web development strategy of ‘progressive enhancement‘, where a non-flash-enabled site visitor (like the Googlebot) would be able to access at least the core content, and the more capabilities the visitor possessed (CSS, rich media), the more enhanced their experience. In addition to potentially increasing maintenance costs (to ensure the two versions were in sync), implementing this method is sometimes not feasible at all, depending on the complexity of the application.

I was eager to see how what I knew about Flash accessibility best practices came into play, and eagerly read through the documentation. As I did so, however, I found I had more questions than answers. In the Google Webmaster Central Blog, there is an intriguing statement:

we do not generate any anchor text for Flash buttons which target some URL, but which have no associated text.

When I first read this, I believed it meant that some links may not be followed. This makes sense from the standpoint that a button with no associated text would essentially be a hidden link, and following it may inaccurately represent the content of the site. However, the statement actually focuses on the generation of anchor text. I am not clear where this generation would take place; perhaps in a virtual buffer of all the Flash content? How does the content of the link (assuming that it DOES get followed) get associated with the overall Flash content (since there is no anchor text).

Another consideration is the use of tabindices. When coding Flash for accessibility, tabindices may be used to specify reading order. Is this something that search engine spiders will be aware of? Equally, there is a recommendation in the Google docs to “consider replacing the text within an image.. [to make] ..less informative content.. invisible to [Google]“.
This statement made me question of the sophistication of this enhanced player. For years, Google has managed to determine that items such as copyright statements are not significant content items. So why now are they unaware of this fact now that the content is coming from a .swf? The recommendation to move content from an accessible to an inaccessible form seems terribly shortsighted and irresponsible.
We are now quite sophisticated in using semantic markup for html pages to offer search engine spiders some information about the relative importance of elements.I can only assume that all text being pulled from a Flash element is given equal weighting. If this is the case, as is noted in the Adobe Developer Center documentation we will certainly need to see “best practices emerge over time for creating SWF content that is more optimized for search engine rankings”.

Another major challenge in opening applications up to search is being able to direct the searcher to the relevant section within the experience. This is also a concern with accessible PDFs. Much of the documentation recommended the use of deep-linking. However, it’s not clear to me how the spider is made aware of these deep-links. I will admit that my own exposure to deep-linking with a flash experience is limited: we did this for the People’s Choice Awards site, where querystring parameters were fed into the .swf using flashVars. While the Adobe Developer Center documentation mentions this practice (”you can create multiple HTML files that provide different variables to the SWF and start your application at the correct subsection”), I hadn’t been aware that google supported variables in their search result URLs…

There was also some mention made that external files linked to from within the .swf will be indexed, but separately. The implication is that the contents of a data file will show up in search results, separate from its presentational format (and overall context). While I assume this will be resolved in future releases, a diligent developer will likely want to ensure their “include” files are not accessed on their own. I believe my colleagues did something similar when we launched the Wal-Mart Halloween Flash/HTML Hybrid site last year. They did some great work with deep-linking and history management, and handled orphan content loading (I refer anyone interested in the specifics to Toby Miller). My concern is that based on how this functionality was announced (that developers did not need to do anything for their swfs to be indexed), there will be little motivation to ensure content is always delivered in the proper context.

Obviously, I am very interested to see if this development will enhance the experience of users of assistive technologies. Sadly, I’m not sure it will, as the major breakthrough has been made with the enhanced player. Unless Adobe also plans to work with makers of assistive technologies, I don’t know that any of these benefits will be realized. If anything, site designers may stop some of their earlier practices (textual alternatives).

I’m very interested to know if any of the accessibility properties and best practices have made it into this enhanced search — how great would it be if the use of these properties increased the weighting of content!

As a front-end web developer, I often hear the terms “findable”, “searchable”, “indexable” and “accessible” thrown around interchangeably. For many, they mean that the content can be accessed by a non-human, be it a screen reader or a search engine spider. On some level this is true, but there are several significant differences that are must not be overlooked.

For the sake of this discussion:

• Findable: how easily a site can be found when using a search engine (rankings). Yes, I realize that this term also refers to how easily content can be found once the user is on the site, but I’m ignoring that aspect of it for now…
• Searchable: how easily specific content within a site can be accessed when using a search engine (deep-linking)
• Indexable: how easily the content of a site may be retrieved and used in search engine results
• Accessible using AT: how easily someone using assistive technologies can use your site

(ShoeMoney.com has compiled a list of definitions for SEO from some industry experts, as well)

A site created completely in Flash or Flex may be findable thanks to the use of meta-data, but it is not indexable. With some diligent coding, information may be searchable, but this is no guarantee that it will be accessible.

(Not content with these descriptions? Have more to add? Please let me know what you think in the comments!)

As I’ve mentioned, my background is in accessibility: prior to coming to Resource, I worked on large subscription-based web applications. SEO was not a consideration at all. However, accessibility was. When I first came to Resource, I was eager to see how the two complemented and contrasted each other.

Overall, I see some overlap between the areas. However, their focus is different.

SEO is based on a page mentality - this is apparent in the search results that come up. Many common SEO techniques are applied at the page level, via adding meta tags or optimizing title tags. This is how a site that requires login, or is built using a technology like Flash or Flex, can appear in search results. A search engine can access meta information about the page, and use that to rank it. Findability relates to the notion of the discovery of the page itself.

A secondary notion is that of searchability. A web application may be found on google, but can the specific content that is being sought be retrieved? Searchability refers to the idea that site visitor can easily navigate to the specific information he’s searching for within the site, once the site itself has been discovered.

Both searchability and indexability deal with how elements of the page can be accessed, but arguably in different directions. Deeplinking into a flash movie may facilitate searchability, helping a site visitor dig into the site at a specific point. In contrast, indexability refers to the ability of a search engine spider to do a broad pull of content from the site.

Where SEO and Accessibility really start to diverge is when we move beyond the retrieval of content itself. A search engine spider is only interested in the data, so that the appropriate search result may be returned to an information seeker. In contrast, accessibility refers to the ability of a site visitor to navigate within an experience. The implications are significant: each interaction must be coded in a way such that a screen reader user can activate the change, and be notified of any changes that occur.

Another important distinction is the extent to which the site content is made available. A site may work to optimize or only make indexable certain aspects of the site. In contrast, accessibility refers to the ability of all content to be available and able to be engaged with.

Here are the slides from my second presentation from Spring <br />. Coming into this presentation, I was less nervous than about the first, which in some ways I believe contributed to a weaker presentation.
I had asked the conference organizers if I would have the same audience in the two sessions, and it was generally believed I would. As a result, I had expectations about a certain level of background information. When I started the presentation, I realized quickly that other than a few familiar faces from the morning, I was speaking to an entirely different group.

I did try to engage the audience a little, and learned a bit from them. Almost everyone in the room had done some flash, but only one or two had ever heard of the accessibility properties available. And whereas a few people in the morning session had indepth knowledge of specific screen readers, that was not the experience in this session. I asked if anyone had ever seen anyone use a screen reader, to little to no response. I got to joke “great, that means you’ll believe anything I say!” In retrospect, I think a session on how users use assistive technologies would probably be very eye-opening and interesting.

So here is the slide deck - as I said, it’s rather weaker than the one from the morning. I had weathered numerous questions in the morning, and had expected the afternoon to run similiarly. However, I think I only had a single question, so we breezed through it.

| View | Upload your own

As promised, here are the slides I presented at the Spring <br /> conference on Tuesday.

Web Accessibility Acronyms was the first presentation of the breakout sessions, right after the morning keynote. I felt a bit nervous as I set up, but the proctor helping out was very nice and we chatted away before I started, which lightened the mood.

Overall I think it went quite well - the night before I’d rearranged my slides and things didn’t flow well, so I did some shuffling back and forth mid-stream. As well, I was asked if I could increase the contrast on the slides - the template we’d been given was black on blue and was difficult to see. Even the little technical glitch almost seemed to fit, as I later could talk about the color contrast ratios that are in WCAG2.0. Foreground and background colors can be analyzed to ensure there is sufficient contrast. Whoops, guess I would have failed!

It was good to have folks in the audience asking questions. Someone did have a comment about flash being inaccessible, and I hedged a little, since that was a major point in my presentation to come later in the day. I think I lost him after that, at one point he looked to be reading a book!
Even though it certainly wasn’t to a group of 75 (as I had been warned about), I was happy with how the speech went. Through the rest of the day, I had a few people stopping me to ask questions, which I was glad to answer. I felt it was pretty well received.

I do feel bad for the rough nature of these slides, in particular the lack of citations. Mea culpa.

| View | Upload your own

A few of the terms I’ll be covering in my session on Web Accessibility Acronyms tomorrow:

Regulatory Compliance: Section 508 (VPAT), WCAG1.0, WCAG2.0, ADA, DDA

Involved Parties: W3C, WAI, United States Access Board, AIA
Screen Readers: JAWS, Fire Vox, Window Eyes

APIs: MSAA, IAccessible2, UI Automation

RIA: WAI-ARIA, AxsJAX, AjaxAID

This week I’ll be presenting two topics at Spring <br />, Web Accessibililty Acronyms and RIA Accessibility. As I was pulling together some resources to share, I pulled out a blog post I wrote for our Resource Interactive Technology blog. I figured I may as well share it here as well…

Is your site accessible? Web accessibility is making the news, with the target.com lawsuit[1] the most notable. It’s no longer enough for a developer to know Java, .NET, PHP, AS, HTML, CSS, JS, XML (insert other TLAs as applicable), now they’re expected to be experts on WCAG, W3C, ADA, WAI, WAI-ARIA, JAWS and Section 508, as well?

Is what we’re doing accessible? How do we know?

Testing for web accessibility is challenging; there are consultants[2, 3] who make their living on it, and many comprehensive (expensive) commercial tools[4]. However, there are several simple tools a developer can use to ensure he’s being conscious of some of the common barriers to accessibility.

Note: there is a difference between making a site comply with accessibility guidelines, and making one that is usable by people with different disabilities. The former may be assessed to some extent by automated tools, but user testing is really required to ensure a site is usable and provides visitors with a positive experience.

Automated testing isn’t infallible, and not all the guidelines are verifiable by automatic means. It’s been estimated that only about 25% of accessibility errors can be verified automatically. As well, the tools themselves aren’t perfect. Jim Thatcher[5] and Gez Lemon[6] have posted reviews of automated testing tools on their respective websites. Passing an automated validator does not guarantee a site will be accessible! However, it is more likely to be accessible than one that does not validate.

FireFox: a developer’s best friend

There are many FireFox extensions related to accessibility. A few of my favorites:

FireFox Accessibility Extension: Similar to the standard web developer toolbar, this offers many features related to accessibility. The “report” option applies to a single webpage, and records the frequency, severity and rationale for each reported issue. https://addons.mozilla.org/en-US/firefox/addon/5809

FANGS: A screen reader emulator. For anyone who’s tried to use a screen reader, it can be very hard to understand (and navigate!) FANGS offers a textual representation of how a page would be read on page load. This helps to see if content is accessible, but doesn’t help in terms of interaction. http://www.standards-schmandards.com/projects/fangs/

Fire Vox: For those not content with a screen reader emulator like FANGS, Charles Chen has created a fully-featured screen reader for FireFox. It reads changes made to the DOM, and does not have access to changes that occur within plugins (like Flash). Fire Vox does have support for live regions marked up for WAI-ARIA (proposed markup to help make AJAX accessible) http://firevox.clcworld.net/

Color Contrast Analyzer: This tool is moreso for designers than developers: it can be used to determine if the foreground and background colors of elements have “sufficient contrast.” This functionality is also available via the FireFox Accessibility Extension listed above, I haven’t compared the output from each. http://juicystudio.com/article/new-improved-colour-contrast-firefox-extension.php

Other techniques

Accessibility doesn’t just refer to blind users with screen readers. Color-blind, short-sighted and mobility-impaired users need to access your site as well. The following techniques can help you understand their experience.

Throw your mouse out the window: Tab through your site. Is it a painful process to actually get to the content on your page? Can you access all the actionable items?
Using skip navigation and semantic HTML markup can help *

Resize your font: Most browsers allow users to resize their font using keystrokes. What happens to your site when you increase your font size once or twice? Is it still legible?

Disable JavaScript: Can you perform all essential site actions without it?

That OTHER browser

Although I mention several FireFox extensions, it’s commonly believed that most users of screen readers are using Internet Explorer on Windows. There are some differences in how the different browsers interact with assistive technology, so it is imperative to perform testing in both environments. Vision Australia has an accessibility toolbar available for Internet Explorer: http://www.visionaustralia.org.au/ais/toolbar/

No one sets out to build an inaccessible site, but sometimes the end result is such. We may not be able to offer a visitor using assistive technologies (screen readers, screen magnifiers, pointing devices) the same rich, engaging experience as other visitors, but we should work to provide him with something. These tools help ensure at least some of the common barriers to accessibility are removed.

* Most screen readers allow users to bring up a “links list” or “headers list” so the visitor can navigate quickly to the section they’re interested in. HTML button or submit elements allow for a keyboard user to submit a form more easily than images that evoke JavaScript for form submission.

Citations

[1] http://www.eweek.com/c/a/Retail/Court-Rules-Against-Target-in-Web-Site-Accessibility-Lawsuits/
[2] http://www.wats.ca/showcategory.php?categoryid=14
[3] http://jimthatcher.com/
[4] http://jimthatcher.com/testing2.htm
[5] http://jimthatcher.com/testing1.htm
[6] http://juicystudio.com/article/invalid-content-accessibility-validators.php

(from the accessibility_sig mailing list)

As part of a TCDD funded project called AccessWorks, Knowbility has been able to hire interns with disabilities to perform web site accessibility assessment, to research employment and disability related topics on the web, and to blog about their experiences. While our interns have found a great deal of documentation out there about barriers to accessing information online, much less is available about how people with disabilities are producing content and successfully posting to the web. Expect to hear from them about that and other related topics.
Check it out at www.universallydesigned.net

One excerpt, posted by Desiree: “This is my first experience with blogging, although I have read lots of other people’s stuff. I am totally blind, using jaws and have experienced a few slight barriers. First off, I hope I am putting this text in the correct area, because jaws doesn’t tell me much about where I am. I also found that when viewing posts, I have to scroll past all of the top text to see the post’s content.”