E-mail List Archives

Re: Well formed verses Valid code

for

From: Phil Teare
Date: Feb 26, 2007 8:10AM


>
> Surely the author/CMS should put the snippet in a pre and/or code?
>

Got to admit, pre was new to me (I really don't know everything...), but my
thought is that containing in a div and 'warning' the reader is a good plan
to help the user avoid running into code. Even if the AT has a setting to
not read <code> elements, the chances are the user doesn't know where that
setting is, and even if its encoded.


> And just a code element for inline bits. Anything in a pre, code, var,
> kbd etc. could justifiably have a different rendering, audio or
> otherwise.

Yes but the user wouldn't get as much warning. Its an entirely subjective
design issue that I'm putting forward, but I think its fair (airing now, in
part to see if you and others agree though)...

I guess the hard part is authors who don't encode their content
> snippets?


Unfortunately not. Like I say the TTS engine (which is not under the
assistive technology's control developmently speaking, and often not
entirely programmatically speaking) is too often the cause for concern. Even
with encoding. Especially as the AT may decode it to read it (bepending on
text format issues).


> In which case uuencoded ampersands would cause issues,
> although perhaps not when in an attribute such as href?


Not quite so much as they are 'simple' and common. So its easier to program
around any issues. Unlike 'CODE' which is infinitely complex in its possible
form and effect... So I feel loathed to accept responsibility for trying to
get it read perfectly every time...

> e.g. if any of the code snippet looks like the TTS engine's take
> on SOAP, SAMPA, IPA, or more likely its own proprietory XML based
insertable
> command strings (for a section to be read faster, louder, by a
different
> voice etc...),

Are certain UAs are looking for their own custom XML snippets in the
> page? Surely that would encouraging inline, agent-specific styling/code?


Some text to speech engines are. I'm sure you're aware, but incase you're
not:

The assistive techs (JAWS, Talklets, Opera, Eyes, etc...), be they the
browser, some script and a plugin, an independent installed app connecting
to the DOM via the OS or UA's API,... all use TTS engines which are not
theirs. Moreover, could be anyones. e.g. you can use L&H voices, or AT&T or
Nuance, or Elan, or.... on any of the ATs affore mentioned. Most of these
will receive and act upon command strings. These strings are often XML-like
(hense to risk of inadvertantly triggering commands/re-parsing badly or not
reading at all due to little known settings). Unsuprisingly, there are more
standards re these embeddable command strings than engines!!! Many
proprietory, but just as many not.

While its unlikely the VoicXML enabled engines will be caused issues due to
the AT passing it malformed code, other embedded string command protocols
are more easily confused/accidentally triggered...

So unlike most folks take on accessiblity, we're not just in a mess of Web
developers who care, Web Developers who don't, Assistive Tech developers,
Web Standards and User Agents - the text to speech engines themselves are
also in the mix of 'Things to Worry About' when pages contain special
charecters and 'code'...

:(

Phil


--
Phil Teare,
Technical Director & Lead Developer,
http://www.talklets.com from Textic Ltd.
(44) [0] 77 68479904