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.

My topic suggestion for Spring <br /> has been accepted. On June 3rd, I’ll be presenting the following:

Topic: Making RIAs Accessible
Description: Rich Internet Applications offer the site visitor a more interactive, engaging experience. But can this richness be conveyed to a user of assistive technologies, and how?
This session will differentiate between DOM-based (AJAX) and Plugin-based (Flash/Flex) RIAs in terms of navigation and notification of changes taking place. We will look at current and proposed best practices and techniques.

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

Ah, the fun part of a research project: when you know just enough to be dangerous…

Trying to figure out the scope for my capstone, I’ve done some reading on WAI-ARIA, which seems to focus on helping making AJAXy-applications accessible via roles and states. However, we really work more with flash and flex at work, and I want to figure out how to push accessibility via those mediums as well. I came across a great resource at niquimerret.com, a girl geek who is passionate about both Flash and Accessibility. Perfect! I read a post she’d made on accessibility “bugs” in flash, and left her a long rambling comment on some of my questions about flash and accessibility. I figured I may as well leave it here as well in the hopes of garnering some additional responses…

One thing I was wondering about, and maybe you can offer some insight: WAI-ARIA mentions using live regions to make AJAX applications accessible. (AJAX live regions allows text to be spoken without giving it focus. This is good in that it means that users can be informed of multiple updates without losing their place within the content.) Is this something that could be coded into the Flash, perhaps at the actionscript level?

My other stumbling point is at which point this would need to be supported… obviously, the flash player would need to understand these roles/states, but is that enough, or would the browser also need to be aware of it? That is.. would flash on FF be “more” accessible than on IE? Or is WAI-ARIA really a browser thing, not a flash thing?

Graduation is scheduled for May 11, 2008.. now I just have to complete my capstone project and I’ll be the proud holder of a Masters of Computer Science degree.

Up until last trimester, the capstone was like a thesis: the student selected a topic, found an advisor and did self-directed study. They recently changed the format to a more traditional class with an instructor and weekly assignments. I was fortunate enough to be allowed to be grandfathered into the old format.

I’m excited about this because it will afford me the opportunity to do some really indepth research into a topic of my choosing. The challenge? The selection of a topic! From what I understand, this was part of the rationale for the format change: students were having trouble finding a topic. My problem is the opposite: there are several topics I would want to write on!

I’ve mentioned in this blog for quite a while that I wanted to write my capstone on “usability-supporting architectural patterns”. I then started thinking about Accessibility in RIAs. I briefly considered doing some research on the Adobe AIR platform, which would have likely meant porting some existing web applications over to the platform to access their differences. Now, however, the term has started and Accessibility/RIAs it is!

The program chair will be overseeing my work, and while I have the general topic in mind, I’m not entirely sure yet what direction it will go in. I fear 12 weeks will simply not be enough to really touch on everything I want to look into. I suppose this is why academics work in the same field for years and years — one can’t really hope to condense everything into a matter of weeks (or a single document).

Some of my thoughts to incorporate into the scope of the project include:
– definitions of: WCAG, Section 508, ADA, RIA, AJAX
– if/how the guidelines apply to non-traditional web apps
– how to make RIAs accessible
– overview of existing testing tools for web accessibility
– ROI/rationale for caring about accessibility

Possibly: how SEO/Accessibility complement/contrast with each other

When I attended Access U last Spring, one of my key interests was in how to sell accessibility to an organization, and who was responsible for it. At the time, the development team I was working on was well informed in best practices wrt accessibility and compliance testing. However, now that I’ve started to fall into a realm of more rich interactive online experiences, there seems to less knowledge of what it means to be accessible, and in fact, the extent to which it is even possible. Obviously I want to sell it to my organization, but I first need to become informed myself as to what that means.

My long term organizational goal would be to sell accessibility to my company, so my capstone will help me to clarify what accessibility means in this new interactive online space. Once we know the “what” and “where” (and hopefully the “how”), we can identify the “who” (and the “how much”)?

so today I threw down my 500 Wii points for the internet channel, in anticipation of being able to watch streaming video on my tv. The wii uses opera as a browser, with flash and ajax support. Sweet!

..until I went to www.pcavote.com and saw a big box stating that express install wasn’t working correctly. Over at adobe’s website, it appeared there was no appropriate upgrade available.

Yes.. I know, had I referred to wikipedia, I would have known that the Wii browser has flash player 7, with no immediate plans for an upgrade being available.

Now I know the version penetration for the flash player: I was involved in a discussion about it just a few weeks ago when there was a flash vs flex discussion at work (flex2 requires flash player 9, whereas we publish flash to play in flash player 8). For those of you not willing to click that last link, as of September 2007, FP7 is at 99.1%, FP8 is at 98.4% in mature markets, FP9 is at 93.3%.

I’d be interested to know how many of that .7% sticking it out with FP7 are forced to

Sure, there are APIs and developer’s guides out there for optimizing applications for the WII in general, but it’s just disappointing that as we move forward, we are still tied to supporting what should be a legacy system, despite the fact it is only being introduced now….

Lately I’ve been doing some reading on mobile apps. I came across a review for Cameron Moll’s Mobile Web Book on 456 Berea Street and then today I stumbled upon an article on “How to make any website a mobile site, with google. The results are pretty interesting! It’s interesting to see how the People’s Choice Awards site, which is very graphic and flash-intensive, came out [link here]. I was happy to see that the entire manifesto on the right was showing up in text — we used the SWFObject technique which had the content written to the screen and then replaced with the flash via javascript. Obviously, this mobile version doesn’t support javascript (or flash) but the content is still available. Nice!

We had had some questions about whether or not google would be able to access/index this information, but my impression based on the fact this came from google is that it is available to them. Good to know!