At 01:54 PM 7/5/2006, John W. Baxter wrote:
>> Does the industry (I almost wrote "do we") know how big a problem
>> this is in practice? That is, what fraction of users of screen
>> readers and other assistive stuff routinely run with JavaScript
>> active?
>>
>> Since the assertion here is "scree
Thank you for the correction, David.
--John
On 7/5/06 5:07 PM, "David Andrews" <[EMAIL PROTECTED]> wrote:
> That assertion is not true, to my knowledge -- and I am a screen reader user.
> Because it does work with a lot of things, and does offer improved
> functionality, it is rare to turn Jav
--On Thursday, July 06, 2006 1:30 AM +0200 emf wrote:
> I had indicated in a
> previous post that the mailman interface I am building
> will be fully
> functional without javascript/css;
Excellent, Ethan. Sorry for the confusion.
Thanks for all of your hard work.
All the Best,
Laura
_
That assertion is not true, to my knowledge -- and I am a screen reader user.
Because it does work with a lot of things, and does offer improved
functionality, it is rare to turn Javascript off.
David Andrews
At 01:54 PM 7/5/2006, John W. Baxter wrote:
>On 7/5/06 11:26 AM, "emf" <[EMAIL PROTEC
>
>I believe that the W3C standards require that Javascript and other components
>fail gracefully, so the point could be made, for things link Lynx and Links
>that a graceful degrade would also take care of us screen reader users.
>Anything specific you write for us, while appreciated, is also
--On Wednesday, July 5, 2006 8:54 PM +0200 emf wrote:
> Are you suggesting I provide *no* link for the
> screen-reader-with-javascript client and let them at some point
> figure out that they're not seeing what's going on and thus turn off
> javascript?
>
> That seems like a worse solution.
I'm
On 7/5/06 11:26 AM, "emf" <[EMAIL PROTECTED]> wrote:
> The problem I face is not when JavaScript is not active, the problem is
> when JavaScript *is* active *and* behaves correctly - i.e. performs the
> dom modification I've told it to - but the browser/screen reader doesn't
> bother to tell the u
Laura Carlson wrote:
> Heavyweight DOM scripting, often results in inaccessible content,
The main point I'm driving at is *any* dom manipulation - heavy, light,
fat-free, or decaf - appears to be invisible to the screen reading user
unless I do it "downstream" of the focused text. I'm talking
emf wrote:
> Gentlebeings,
>
> I have read a depressing and recent article suggesting that DOM
> manipulations are invisible to most screen readers [1]. There are some
> workarounds suggested in [2], but for the most part it looks like
> dangerous territory.
Silly me, I didn't include the link
--On Tuesday, July 4, 2006 9:44 PM +0200 emf wrote:
> I am determined to provide some JavaScript in the 'standard'
> interface, as it will make for enhanced ease-of-use for those sighted
> people using a modern browser.
Hi Ethan,
It says in 6.3 of WCAG 1.0 to "Ensure that pages are usable when
Barry Warsaw wrote:
>> I will do this for browsers not employing JavaScript. Screen readers
>> employ JavaScript and provide no indication what they do/do not
>> provide
>> feedback to the user for.
>
> Will this also work for browsers with JS enabled per-page, a la the
> Firefox NoScript extensio
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 4, 2006, at 2:06 PM, emf wrote:
> Brad Knowles wrote:
>
>> Speaking only for myself, this is not the kind of approach I'd
>> like to see
>> used. I'd prefer to see the web application auto-detect that
>> JavaScript
>> is not available, and
emf wrote:
>> Likewise, it should auto-detect that there is a
>> screen reader being used, and present the appropriate screen reader
>> compatible interface.
>
> This is an admirable goal. One "screen reader" in semi-common use is IE
> 6 via Jaws; another one is Safari with OS X reading turned o
Brad Knowles wrote:
> Speaking only for myself, this is not the kind of approach I'd like to see
> used. I'd prefer to see the web application auto-detect that JavaScript
> is not available, and therefore to automatically present the appropriate
> non-JavaScript interface.
I will do this for br
Ethan wrote:
> Note that this would be in *addition* to the ability to get a JS-free
> version of the interface by using a different URL prefix for any user
> agent that doesn't want the JS action.
Speaking only for myself, this is not the kind of approach I'd like to see
used. I'd prefer to see
15 matches
Mail list logo
