[Athen] Accessibility of standards-based slide tools (was: Accessible Office Export Plug-In That's NOT UIUC)

[skeegan at htctu.net]

> It's actually not CSS that's the problem with S5 and similar tools such as

> W3C Slidy - it's Javascript.


I should have been more clear in my original comments with respect to  
the CSS - I was focusing on the display/visibility properties and  
their relationship to the JavaScript (my mistake).  Great job testing  
on determining precedence with the browsers, screen-readers, and  
scripting.


> The broken S5 functionality actually doesn't matter for Window-Eyes

> users (using version 6 anyway - I haven't tried earlier versions).    

>    Window-Eyes simply ignores CSS and reads everything whether it's   

>     hidden or not. I don't think we can really fault other screen     

>   readers for hiding invisible content though - that would seem to  

> be      a design philosophy rather than a bug. (If something is  

> hidden   from    sighted users, shouldn't it be hidden from blind  

> users too?)


This actually raises an interesting concept as it pertains to a
slideshow-type presentation - should we expect a screen-reader to
follow a visual framework alone as opposed to providing access to content
within a consistent navigational structure?

In other words, to move from "slide" to "slide" in these Web-based
systems, a user would press a specific keystroke to change the
on-screen information.  However, does it really matter as to what is
currently on-screen (visually) if the same content can be provided in
a clear navigational structure?  For instance, in the S5 model, the
Heading 1 represents a new "slide" (I need to check again on the Slidy
tool).  So to navigate from slide to slide is just a matter of
navigating from Heading to Heading.

In some respects, I think Window-Eyes has got this right in that it
ignores certain CSS aspects and provides direct access to the XHTML
document.  The user can navigate from heading to heading (i.e., slide
to slide) in the S5 presentation by simply tapping the "H" key.
Sighted individuals perform a similar function by pressing one of the
other keystrokes to move through the presentation visually.  In either
case, what both individuals are "seeing" is simply a reflection as to
where the focus is in the HTML document.  With S5 and Slidy tool, the
presentation is really just a single Web page that is visually
formatted to appear as multiple slides.  The fact that JAWS only reads
what is visually on the screen is (IMO) following a sight-dependent
model for providing access.  While you can certainly get to the
various slides with JAWS, it is not easy (or consistent).

First and foremost, I would argue that access to the content in a
consistent, logical manner is necessary and adherence to following the
visual model should not come at the expense of that aforementioned
access.  However, I believe I must ask, what do more experienced
screen-reader users prefer?

Side note - I do agree that there are some cases where the content
should be hidden from both sighted and screen-reader users and only
revealed upon demand  (but that is a topic for another discussion).


> If we agree that keystrokes should be passed through assistive

> technology before being handled by a web page's Javascript, how has Eric

> Meyer accomplished this with S5?


Good question. I would be interested to know what was going on as well  
- perhaps just a happy accident?  Looking at the JavaScript there is a  
reference to 'alt' but I believe this is referring to Access Keys.   
Wouldn't it be cool if the "H" key was set to only move focus to the  
next heading as it currently does, but also shift to the next slide  
visually?  Keyboard intercept priority would seem to be an issue here.


> I'm sure this isn't the

> last keyboard-enabled web application we'll be seeing.


Absolutely correct.  The rise of RIA is on the way and is not slowing down...

Take care,
Sean

Quoting Terry Thompson <tft at u.washington.edu>:


>> Turning off the CSS in the browser seems to improve the presentation

>> navigation with JAWS tremendously...which raises a very

>> interesting question as to why does CSS have so much control

>> over how JAWS functions?!?.

>

> It's actually not CSS that's the problem with S5 and similar tools such as

> W3C Slidy - it's Javascript. Each of these tools is similar in that they

> take a single HTML file, then intermittently hide and reveal portions of it

> in order to create the slideshow effect. This hiding and revealing is

> accomplished in part using CSS - but the real behind-the-scenes magic is

> performed by Javascript. The problem for screen reader users is that

> Javascript is intercepting keystrokes and interpreting them to be S5 or

> Slidy commands, whereas the user might have intended those keystrokes to be

> handled by their screen reader.

>

> The variance in behavior across versions and browsers is what really

> interests me though. Using the latest versions of everything (JAWS 8,

> Internet Explorer 7, and Firefox 2) the precedence of which application is

> first in the keystroke chain seems to go like this on a web page that

> contains an S5 presentation:

>

> 1. Browser

> 2. Screen reader

> 3. Web page/Javascript (S5)

>

> In this scenario, screen readers read the presentation pretty well, but the

> S5 navigation is broken.

> For example, users are supposed to be able to advance slides with Space bar,

> Return, Right arrow, Down arrow, and Page down, but if either the browser or

> the screen reader uses these keystrokes for other purposes these keys don't

> work to advance the slides. As Sean mentioned, Alt + right arrow seems to be

> a workaround, but that's only true if the forward button in the browser is

> unavailable. Otherwise Alt + right arrow would be used by the browser as a

> hotkey for the "forward button". Even if Alt + right arrow works to advance

> the slide, one might intuitively expect Alt + left arrow to move to the

> preceding slide, but this is subject to the same restrictions - it won't

> work unless the slideshow is the first web page opened in the current

> browser window. Otherwise it will activate the browser's back button.

>

> The broken S5 functionality actually doesn't matter for Window-Eyes users

> (using version 6 anyway - I haven't tried earlier versions). Window-Eyes

> simply ignores CSS and reads everything whether it's hidden or not. I don't

> think we can really fault other screen readers for hiding invisible content

> though - that would seem to be a design philosophy rather than a bug. (If

> something is hidden from sighted users, shouldn't it be hidden from blind

> users too?)

>

> Interestingly, W3C Slidy, which is a very similar product to S5, does not

> seem to have the same order of precedence for interpreting keystrokes:

>

> 1. Browser

> 2. Web page/Javascript (Slidy)

> 3. Screen reader

>

> This is a much worse scenario for screen reader users, as when they press

> common screen reader keys like the down arrow, Slidy advances the slides but

> the screen reader doesn't read anything. This means that even Window-Eyes

> users are shut out of W3C Slidy presentations.

>

> So, an important question this raises is: What's the difference in these two

> products? If we agree that keystrokes should be passed through assistive

> technology before being handled by a web page's Javascript, how has Eric

> Meyer accomplished this with S5? I don't think Eric subscribes to this list

> so I'll ask him under separate cover and keep you posted. If this is a

> Javascript technique issue as it seems to be, it will be good for us to

> document as a best practice and spread the word. I'm sure this isn't the

> last keyboard-enabled web application we'll be seeing.

>

> Terry

>

>

>> -----Original Message-----

>> From: athen-bounces at athenpro.org

>> [mailto:athen-bounces at athenpro.org] On Behalf Of Sean Keegan

>> Sent: Monday, February 12, 2007 3:01 PM

>> To: 'Access Technologists in Higher Education Network'

>> Subject: Re: [Athen] Accessible Office Export Plug-In That's NOT UIUC

>>

>> > While S5 is great way to create a presentation on the web it is not

>> > really accessible with Jaws as all the keystrokes needed to

>> move the

>> > presentation forward are defined by Jaws to perform dfferent

>> > functions.

>>

>> I think this raises an interesting question as to assistive

>> technology support  of Web standards.  Is the S5 Web

>> presentation model accessible using JAWS?  Sure - but it

>> really depends on what version of JAWS you are using AND what

>> Internet browser.  A presentation with the S5 system could be

>> accessed with JAWS 7.x and Firefox, but not Internet Explorer

>> (JAWS 8 has improvements with IE and the S5 system).  Turning

>> off the CSS in the browser seems to improve the presentation

>> navigation with JAWS tremendously...which raises a very

>> interesting question as to why does CSS have so much control

>> over how JAWS functions?!?.

>>

>> Side note: For using a screen-reader with S5 - to move one

>> screen ahead, press Alt + Right Arrow.

>>

>> Here is my issue though: the S5 system is a standards-based

>> implementation of XHTML, CSS, and Javascript.  I would argue

>> that the developers of such AT need to recognize that better

>> support of Web standards is a necessity and the lack of

>> access is not so much a problem of the presentational system

>> (i.e., S5), but rather poor implementation of the Web feature

>> set by the AT vendor.

>>

>> Granted, there is still an issue of limited access by the

>> individual and that is why I generally advocate the idea of

>> posting multiple formats of the presentation - let site

>> visitors choose the file-type they like the most.

>> However, I do believe that better implementations of

>> standards-compliant (or perhaps standards-supportive)

>> assistive technology is a necessity as we move forward in

>> implementing new models of communication.

>>

>>

>> Take care,

>> Sean

>>

>>

>> -----Original Message-----

>> From: athen-bounces at athenpro.org

>> [mailto:athen-bounces at athenpro.org] On Behalf Of Saroj Primlani

>> Sent: Saturday, February 10, 2007 12:30 PM

>> To: athen at athenpro.org

>> Subject: Re: [Athen] Athen Digest, Vol 13, Issue 11

>>

>> While S5 is great way to create a presentation on the web it

>> is not really accessible with Jaws as all the keystrokes

>> needed to move the presentation forward are defined by Jaws

>> to perform dfferent functions.  I learnt that the hard way Saroj

>>

>>

>>

>> _______________________________________________

>> Athen mailing list

>> Athen at athenpro.org

>> http://athenpro.org/mailman/listinfo/athen_athenpro.org

>>

>

>

> _______________________________________________

> Athen mailing list

> Athen at athenpro.org

> http://athenpro.org/mailman/listinfo/athen_athenpro.org

>