Re: [w3c-wai-gl] <none>

> (Part One: The Socratic Method, or Zen and the Art of
Consensus-Seeking)
>
> With new technologies,

Or indeed decades old technology, the continual love affair with XML
doesn't help, it only distracts.  There's (virtually) never a reason to
invent a new BNXL, so why discuss it's accessibility until all current
technologies have failed to deliver and there's a need to?  I can see no
reason for this to be more than a footnote level thing in the
specification, we have more than enough languages, structures etc. to
provide us with all we need, we should concentrate on ensuring these are
accessible, not encouraging people to invent languages which are
completely inaccessible in reality whatever there theoretical
accessibility.

> (Part Two: JavaScript and its Legacy, or Where Matt Goes Off on a
Tangent)

First note, I think it would be sensible to use the generic "javascript",
without Sun's capitalisation, or if you do not feel that is generic, then
use ECMAScript, JavaScript is a tradename and exists in 2 UA's only AIUI,
(Netscape/Mozilla and AvantGo)

>(And as a plug
> for the techniques format I designed, there is actually room to do just
> that...)

Can you provide a url for this, a search turned up nothing.

> JavaScript is a moving target. Most commonly, accessible techniques
> involving JavaScript center around not around enhancing accessibility,
but
> in keeping JavaScript from hindering it.

I disagree, depending on what you mean by accessibility, form validation,
menu systems, are all about increasing the accessibility of a page,
obviously from a comprehensibility point of view, rather than relating to
specific interested groups.

> This has to do with preventing
> JavaScript from hiding textual content from the user in the myriad ways
the
> language does so.

The language doesn't hide anything, the (incompetent?) script authors
choose to hide it, there is a distinction in my mind at least.

> Still, JavaScript has a role in modern browser development
> as a rudimentary evaluator of browser capabilities, for example, which
> cannot be overlooked.

Please explain?  Either javascript can provide a lot more than
rudimentary evaluator of browser capabilities or it can do very great
harm (cf. Object Detection, over Browser Detection.) Rudimentary attempts
almose certainly do more harm than good.

> It can also provide good usability gains: most search
> engines use it to focus on the search text input.

This is not a usability gain, this I find so unusable as am forced to go
to great lengths to customise my browser so it doesn't happen, automatic
focusing is only generally implemented after the onload event has fired,
this means that I've already typed into the first box, and am now typing
in the second only to be forced back to the first. - There are  of course
ways round this, but the current implementations I can't see as a
usability gain.

> Developers should not need to dance around UA idiosyncrasies
> in an effort to make things capital-A Accessible. It seems the division
of
> labor here dictates the solution: there are dozens of UA and assistive
technology
> vendors, and millions of content providers. I think it stands to reason
that
> where the pressure should be brought to bear with respect to compliance
is
> with the vendors. Leaving it to the millions to learn the arcana of
> implementation-specific accessibility design is a waste of time,
> particularly where it dilutes the goal of adherence to published
standards
> (4.2).

I don't see any suggestion of that, indeed I see much less of this bowing
to UA idiosyncrasies in the javascript world than you suggest, if you
look at comp.lang.javascript say, you'll see huge support for adherence
to (the sensible implemented subset) of published _recommendations_ and
very little pandering to the UA's incompatible with this goal.  These
people generally have little or no thought to accessibility, and have the
conclusion through simple good practice.

Also there are areas where there's very broad support amongst UA's, yet
impact on Accessibility, I'm thinking here of  "location.replace" for
example, many UA's now block automatic redirection through META
Refresh's, but there are no UA's (bar my own Snufkin) which block
location.replace - and I don't believe a UA could deliver on these areas
without upsetting it's developer base.

Jim.

Received on Tuesday, 25 September 2001 06:03:14 UTC