MatrixAdapt | Logiciel de gestion d'Entreprise, Création et référencement des sites web

Seo Master present to you: Posted by Charles L. Chen and T.V Raman

As the developer behind Fire Vox I've always wanted to make AJAX web applications truly usable for the blind and visually impaired. The challenge is that these users have to deal with a much higher learning curve than sighted users. Instead of simply learning the controls for a web application, they have to also learn how to get their assistive technology of choice to go to the interesting parts of that application to find out what is currently there.

When I started as a Noogler, I was extraordinarily impressed with the tools that T.V. Raman had built into Emacspeak for efficiently performing specific tasks. An insight that I gained from watching him use Emacspeak is that the application should just say the right thing in response to user actions; users should not have to do an action in the application and then use their assistive technology to go hunting around the screen to figure out what happened.

In my first week at Google, I discovered Google Reader a highly optimized feed reader with very good keyboard support. For my starter project at Google, I decided to access-enable this application using W3C ARIA. Using Greasemonkey, I could inject JavaScript code to add the needed ARIA bits to make Google Reader say the right things at the right time.

Connecting The Dots

Based on the experience of access-enabling Reader, we have now refactored the code to come up with a common JavaScript framework for enhancing the accessibility of AJAX applications. This framework is called AxsJAX, and it was refined in the process of access-enabling Web Search.

We're now excited to open-source this framework since we believe that there is nothing Google-specific in the techniques we have implemented. We invite the Web developer community to help us collectively define a robust framework for rapid prototyping of accessibility enhancements to Web 2.0 applications.

The ability to rapidly prototype end-user interaction has led to an explosion in the number of AJAX applications; until now, visually impaired users have been left behind in this process. We hope that the AxsJAX framework encourages the Web community to bring the power of Web 2.0 development to solving the problem of accessing rich Web interaction in an eyes-free environment.2013, By: Seo Master

Seo Master present to you: By Dion Almaer, Google Developer Programs



T.V. Raman is a Research Scientist at Google who knows a thing or two about accessibility. We took the opportunity to interview him, and Hubbell, his seeing-eye dog (who was nice and quiet).

We started out by asking the honest question that developers ask about accessibility: "What is in it for me?". T.V. discusses the practical issues, and what you should be doing with respect to accessibility, and how it is one piece of the usability picture.

We then delve into the problems of developing accessible websites, and solutions to some of the problems.

If you listen to the interview you will learn:

• How not to develop in a user-agent specific manner
• Fun issues with screen readers
• How audio CAPTCHA brings equality to the pain of CAPTCHA, and how people who can see use the audio ones
• How painful is the Web to view for a blind person
• Using the Google Web Transcoder (the other GWT!) to clean up pages
• How CSS hasn't been as leveraged as much as we would like
• How the increase in mobile and widget platforms has a side effect of accessible views
• How RIA applications deal with accessibility
• How T.V. has written custom clients for Google APIs
• What standards groups are doing in the accessibility space
• Dealing with Python, a language that cares about whitespace, as a blind man.
  

You can download the episode directly, or subscribe to the show (click here for iTunes one-click subscribe).

Also, check out an accessible web search for the visually impaired.2013, By: Seo Master

Seo Master present to you:

Did you notice the new Interactive Transcript feature that lets you scan quickly through the full text of any owner-captioned video that you’re watching on YouTube? For videos from I/O, that means you can quickly scan through a 60 minute talk to find just the part of the talk that you need to see. Or use your browser search with the Interactive Transcript to find a mention of an API call, and then click on a word in the transcript to jump straight to that part of the video.

Because developers don’t all speak English (and because some developers speak really fast when presenting) we caption every video that we post to http://www.youtube.com/googledevelopers. Most of the year, that’s a pretty easy thing to keep up with. But last year, when we posted all the videos for Google I/O 2009, it took us months to get everything done.

This year, we captioned everything within 24 hours or less of the videos going live. I’m excited about that, because it wouldn’t have been possible without the new auto-caption and auto-timing features in YouTube. We also did something a little nerdy -- we used four different methods of captioning.

If you use YouTube to share talks from your own developer events, you might find this summary useful.

The two fastest options for producing and cleaning up our captions used auto-timing. We uploaded a transcript and had YouTube’s speech recognition calculate the timecodes for us.

The two auto-timing methods were:

• CART live real-time transcript + auto-timing
  Because we had professional real-time transcriptionists at I/O, we could instantly caption anything that had a live session transcript. That’s how we got the keynotes captioned on the day of the event. We also used this method for the android talks.

• Professional transcription + auto-timing
  This was less expensive than CART, and faster than full captions with timecodes, but slower than real-time transcription because we had to get video files to the transcribers.

Although these methods were fastest, auto-timing turned out not to be perfect for all videos. When mic quality varied, or we had too many speaker changes in a short period of time (e.g panel discussions or fireside chats), the timing sometimes slipped out of sync. You can still use the Interactive Transcript to see what was said, but it’s not ideal.

The two slower methods that we used were:

• Pure 'traditional' captioning
  This is what we did last year for Google I/O 2009 videos. It’s slower, and more expensive, because you have to transcribe and set all the timecodes correctly. But the end result is 100% accurately timed. We did this to fix a video that the auto-timing had a lot of difficulty with.

• Speech recognition (auto-captions) with human cleanup and editing
  This gave us perfect timecodes, just like traditional captions, and took less time than traditional captioning. It took slightly longer than auto-timing alone because we had to download the machine-generated auto-captions from YouTube to do the edits.
  
  Automatic captions are fantastic if you don't have time or budget to put any work into your captioning. But for I/O, we wanted our captions to be perfect on technical terms, so fully automatic captions weren't the best fit.

Not all of these methods are equal in terms of quality, but it’s interesting to compare. To see which method was used on a video, look for the track name in the caption menu. To compare owner-uploaded captions with pure machine-generated auto-captions, you can always choose ‘Transcribe Audio’ from the caption menu for our videos.

If you’d like to help improve caption quality, please watch a video and fill out our caption survey to tell us what you think of these captions! We know some of them are going to be a little off -- if you report issues, we’ll fix them.

By Naomi Bilodeau, Google Developer Programs2013, By: Seo Master

salam every one, this is a topic from google web master centrale blog: this is a topic published in 2013... to get contents for your blog or your forum, just contact me at: devnasser@gmail.com