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.

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”)?

Today I attended a three hour session at Microsoft on “Architecting for the User Experience“. It was geared towards architects and senior developers, so I thought I would check it out.

The first half of the session was a generic “What is UX” spiel. The take-home? “UX is a bloodbath and you need to fight for it, but it’s worth fighting for”.

There was a slide about how generally people felt UX = UI, and that the GUI was like icing on the cake; it could make it look good, but it couldn’t change any underlying problems. Having just attended a birthday party with three year olds last week, I wasn’t so sure this was a great analogy - put on enough icing and kids won’t even get to the cake!

A few links were tossed around:

• joshholmes.com
• designthinkingdigest.com
• visitmix.com
• microsoft.com/design

“Questions about whether design is necessary or affordable are quite beside the point: design is inevitable.

The alternative to good design is bad design, not no design at all.”

– Douglas Martin (designer)

1. Functionality: “works great”
2. Aesthetic: “looks great”
3. Interaction: “relates to you” (example was espresso machine that makes two cups)
4. Process: emotional experience. Every moment you spend with something you dislike, you could be spending time better

I was bothered by the fact that the next slide said “business principals”. I will admit I was so caught up in the grammatical error that the point the speaker was making was lost on me… Hey, attention to detail….

The speaker (Josh Holmes) used some great examples of products that had great and poor user experiences. I had never seen the innovative pill bottles used at target, but I’ll admit they are of great design. He shared with us many interesting tidbits - did you know Harley davidson forecasts their next year’s sales based on the number of Harley Davidson tattoos being {what do you do with tattoos? create them? make them? commissioned, perhaps…} in a given year. Naturally I started thinking about brand and marketing, but I know that wasn’t on the formal agenda for the day…

Three questions to ask (and answer!):

• What is desirable to users
• What is viable
• What is possible

The second half of the session was the sales demo. Josh mentioned the continuum of experience, from the web (ubiquitous) through to platform-optimized, with an intermediary of “richness” between them. In MS terms, it was “asp.net/ajax” to “silverlight” to “wpf”. I had heard of silverlight, but didn’t know much about it.

I’m generally a bit skeptical of MS offerings, but I’ll admit, this stuff was slick. Earlier in the session we had talked about travel applications, and he brought up a silverlight demo of one. Now this thing is slick! An entirely different experience than that we’ve become used to when booking flights. Heck, it was fun. Is that the technology, or simply the vision? I’m not sure: flash/flex may be able to handle the same thing.
I would link to a working demo, but I just tried installing silverlight, to no avail.. so here’s a blog post with some screenshots. *sigh… no comment*

Josh pulled everything up on vista without any real explicit mention of it… and my initial impression was “wow, that looks like a mac!”

Some general notes: MS is looking at 3 - 9 month release cycles, rather than years and years between releases. They released the 1.0 beta the same day as the 1.1 alpha.

• Silverlight 1.0: this summer
• Silverlight 1.1: (with or after orcas – dependent on CLR, late fall, early spring)
• All apps run in the sandbox
  • Conceptually similar to HTML DOM sandbox
• Apps run like HTML pages – click a URL
  • No elevation of privileges request
  • No way to get out of sandbox
• Includes some additional functionality
  • Safe isolated storage
  • Client based file upload controls
  • Cross domain support in-work

So what was the big sell? “So as .NET developers, what can this do for you?” (whoops, I’m not a .NET dev)
The resounding answer was “No HTML!” Evidently “HTML is the COBOL of the web”

Currently, designers design, and developers add business logic. XAML enables them to speak the same language.

We got to see the entire suite:

• Expression web: xhtml, css, xml, xslt “arguably one of the best css editors available”
• Expression design: pro graphic designer tool (photoshop).
• Expression blend: Visual studio for designers. Integration of art, images, text, video, 3d content
• Expression media: supports over 100 file formats, version control, folder watching..

No special hosting requirements (*.dll, *.xaml, *.js, *.html), cross platform client side functionality you can host anywhere.
The speaker mentioned that he foresees a “technical director” role coming into the field in future years.

Overall, I was pretty impressed with what I saw. I’m not generally a huge MS fan, but I’d be interested to see where this all goes…

Like it? Share it! These icons link to social bookmarking sites where readers can share and discover new web pages.
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 

I just signed up to attend Access U. I then tried to enroll in the “Real World Accessibility for Ajax and Web Apps” seminar the day prior. There was some problems in registering, so I called the info line and got on the phone with Derek Featherstone himself.

Turns out they are announcing later today that the workshop is going to be postponed due to lack of interest. Booo! He did ask if a September date worked better for me, but I said that I was in Ohio, and so I wouldn’t make it out to Texas for a one-day session. At that point, he asked me a bit more about the Midwest, if there would be some interest locally. I told him that I certainly felt so. I told him how some of us went to Chicago last year for a conference and it would be great to have it closer. He did ask which was the better location, Columbus or Cincinnati, and I hestitated between the two. Ultimately, though, I expect Columbus would be a bit better… (?) So anyhow, he said he would get in touch with me, so perhaps we can arrange something closer.

So the bad is: no workshop next month. The good is: hopefully we can bring something local!

-Look at fixing AJAX rather than simply saying “it is not accessible”. Nothing in AJAX is inherently accessible or inaccessible. It’s about implementation

Common problems
—”js support is spotty” (10% of browsers don’t support JS)
—doesn’t meet WCAG1.0
—bookmarking/back button issues.

Solutions
–provide indication of scripting requirement
—provide notification of state change
*note, some of these visual indicators can be overwhelming even to sighted users as well (just because you can do something, doesn’t mean you should)
—update elements with new content rather than creating new elements

However, these solutions still don’t make them accessible to screen reader users. This is due to how screen readers work.

Screen readers read from a content buffer, so it does not notice changes until the buffer is refreshed.

SR Modes:
visual PC cursor - interacts with buffer
forms mode - bypasses buffer, interacts with onscreen elements. Theoretically, any AJAX functionality occuring on a form should be picked up.

-JAWS/FF refreshes buffer more often than JAWS/IE

-Right now, AJAX issue is somewhat a philosophical one. Hard to say whether it will or will not work. So do we wait for screen readers to catch up, or do we start implementing it now?

JW: my opinion is we don’t wait (probably not popular in the accessibility field). It’s in the implementation we figure out what will or won’t work.

ME: so if users can reload the buffer, can we simply instruct them to do so when they do something AJAX-Y?
JW: that may be a solution

Another link I found (not sure of quality of content: http://juicystudio.com/article/making-ajax-work-with-screen-readers.php)