RE: [user-assistance-discuss] Thoughts on Graphical Callouts

["Bill Burns" <wdburns@cableone.net>]

One of the added values of semantic markup is that you can provide
alternatives. I absolutely agree with Paul Neshamkin that excluding graphics
is absurd. However, an XML schema should be able to include options. Where a
figure might include a legend in a printed guide or popups in an online
rendering, the same markup could include more detailed textual information
about a graphic image.

At the same time, some of this has nothing to do with the markup used to
capture information and everything to do with the rendering. For example, if
my schema includes markup for alternate text in graphics, it doesn't do me
much good for PDF output if RenderX and AntennaHouse don't support tagged
PDF. 

Bill Burns
Burns Technical Communications
Microsoft Help MVP
wdburns@cableone.net 

> -----Original Message-----
> From: marbux [mailto:marbux@gmail.com] 
> Sent: Tuesday, May 09, 2006 9:30 PM
> To: Irwin, Barbara
> Cc: Paul Prescod; user-assistance-discuss@lists.oasis-open.org
> Subject: Re: [user-assistance-discuss] Thoughts on Graphical Callouts
> 
> On 5/8/06, Irwin, Barbara <Barbara.Irwin@eclipsys.com> wrote:
> >
> > That's an interesting point, but users can be handicapped 
> in many ways 
> > - including some who cannot read.
> 
> 
> That is a true statement. Blind people are an example, except 
> for those who have learned to use electronic Braille 
> displays. See < 
> http://en.wikipedia.org/wiki/Refreshable_Braille_display>. 
> JAWS (Jobs Access for Speech) is presently the most widely 
> used screenreader program for Braille readers, but is limited 
> to DOS and Windows. < 
> http://en.wikipedia.org/wiki/JAWS_%28screen_reader%29>. While 
> JAWS can convert screen text to speech via voice 
> synethesizer, its functionality is largely one-way. It adds 
> little to an end user's ability to control applications.
> 
> Others who can not read include sighted people who have never 
> acquired the skill. If that was the group you had in mind, 
> graphics are not a good solution to their problem. E.g., how 
> are they even going to find the Help menu at the top of the 
> application's screen if they can't read? How are they going 
> to navigate within the Help system? And even if you get past 
> that barrier, how many images would have to be created to 
> translate all of the text in a Help system into 
> understandable graphics?
> 
> The way forward for Help systems is a combination of web 
> browsers, text, markup, VoiceXML, and its related standards.  See <
> http://en.wikipedia.org/wiki/VoiceXML>:
> 
> >>>
> 
> "VoiceXML (VXML) is the
> W3C<http://en.wikipedia.org/wiki/World_Wide_Web_Consortium>'s
> standard XML <http://en.wikipedia.org/wiki/XML> format for 
> specifying interactive voice dialogues between a human and a 
> computer. It is fully analogous to HTML 
> <http://en.wikipedia.org/wiki/HTML>, and brings the same 
> advantages of web application development and deployment to 
> voice applications that HTML brings to visual applications. 
> Just as HTML documents are interpreted by a visual web 
> browser, VoiceXML documents are interpreted by a voice 
> browser <http://en.wikipedia.org/wiki/Voice_browser>. A 
> common architecture is to deploy banks of voice browsers 
> attached to the public switched telephone network
> (PSTN<http://en.wikipedia.org/wiki/Public_Switched_Telephone_Network>)
> so that users can simply pick up a phone to interact with 
> voice applications.
> 
> "There are already thousands of commercial VoiceXML 
> applications deployed, processing many millions of calls per 
> day. These applications perform a huge variety of services, 
> including order inquiry, package tracking, driving 
> directions, emergency notification, wake-up, flight tracking, 
> voice access to email, customer relationship management, 
> prescription refilling, audio newsmagazines, voice dialing, 
> and real-estate information. They serve all industries, and 
> range in size all the way up to massive national directory 
> assistance 
> <http://en.wikipedia.org/wiki/Directory_assistance> applications.
> "VoiceXML has tags that instruct the voice 
> browser<http://en.wikipedia.org/wiki/Voice_browser>to provide 
> speech synthesis 
> <http://en.wikipedia.org/wiki/Speech_synthesis>, automatic 
> speech recognition 
> <http://en.wikipedia.org/wiki/Speech_recognition>, dialog 
> management, and soundfile playback.
> 
> . . . . .
> 
> "Two closely related W3C standards used with VoiceXML are the 
> Speech Synthesis Markup Language (SSML 
> <http://en.wikipedia.org/wiki/SSML>) and the Speech 
> Recognition Grammar Specification 
> (SRGS<http://en.wikipedia.org/wiki/SRGS>).
> SSML is used to decorate textual prompts with information on 
> how best to render them in synthetic speech, for example 
> which speech synthesizer voice to use, and when to speak 
> louder. SRGS is used to tell the speech recognizer what 
> sentence patterns it should expect to hear."
> 
> <<<
> 
> See also World of VoiceXML. <http://www.kenrehor.com/voicexml/>.
> 
> Now let's take a quick look at a VoiceXML implementation, 
> HAWHAW, a rapidly rising star in the open source software 
> scene. <http://www.hawhaw.de/>.
> HAWHAW is licensed under the Gnu Lesser General Public 
> License, (The same license is used for OpenOffice.org, and  
> allows Sun Microsystems and IBM, among others, to incorporate 
> OOo code in, respectively, the StarOffice and IBM Workplace 
> proprietary applications.)
> 
> >>>
> 
> "With HAWHAW you can publish WAP pages which are also 
> accessible by HTML standard browsers. HAWHAW automatically 
> determines the requesting device's capabilities and creates 
> appropriate markup code. Many users confirmed that HAWHAW 
> created WML output is compatible with a lot of mobile devices.
> 
> "You don't have to care about all the different browser types 
> available today. The markup language code is generated by 
> HAWHAW in order to achieve a maximum of portability across so 
> many different handheld devices as possible. Especially WAP 
> devices often need browser-optimized WML code for usability reasons.
> 
> "In the early days HAWHAW was a small PHP class library, 
> restricted to create WAP pages. But in the meantime HAWHAW 
> was enhanced step by step and now it is not restricted any 
> more to generate HTML and WML code only! If requested by the 
> user agent, HAWHAW sites are capable to serve XHTML, HDML, 
> i-modeTM , MML, PDA's and voice browsers as well! XHTML (WAP 
> 2.0) is the successor of WML 1.x and bridges the gap between 
> WAP and web applications.
> HDML is some sort of old-fashioned WML predecessor and is 
> still used, e.g.
> in North America. i-mode is currently widely used in Japan, 
> but is expected to become a serious alternative to WML. MML 
> is short for Multimedia Markup Language and is like i-mode 
> used in Japan. PDA-browsers are served by HAWHAW with 
> "handheld-friendly" HTML.
> 
> "Since Version 5.0 HAWHAW additionally supports VoiceXML. 
> That means all HAWHAW applications are voice-enabled per 
> default. The HAWHAW API offers many voice specific options, 
> making HAWHAW a full-featured development tool to create 
> interactive voice applications.
> 
> "And from version 5.6 onwards, HAWHAW supports special output 
> for the Lynx text browser. This "archaic" browser is still 
> used today, often by handicaped people with screen readers 
> and other special equipment. HAWHAW's Lynx support allows to 
> create *barrierfree* applications, which validate 
> Bobby-AAA-approved <http://bobby.watchfire.com/> out of the 
> box and additionally are accessible from each telephone by 
> means of HAWHAW's VoiceXML support."
> <<<
> 
> The existing accessibility electronic assistive technology 
> stack rests on a foundation of hardware and text.
> 
> Software systems are designed for many
> > functions, and the purpose of help systems is to help users 
> navigate 
> > those systems. Graphics (including those that lack artistic 
> merit) are 
> > one of many tools available for that purpose, and can be very 
> > efficient where the written word is not.
> 
> 
> In such situations, how do you meet the informational 
> requirements of the blind? Please enlighten me if you have a 
> solution. I am not close-minded. I allow myself to be 
> persuaded by others every day.
> 
> Individual help authors are in the best position to determine 
> what their
> > users need, and can understand.
> 
> 
> Your first clause is correct but the history of the Help 
> authoring industry teaches your second clause is erroneous. 
> Perhaps you might provide me with an example of your own work 
> for review in regard accessibility issues?
> 
> 
> They're the ones who receive feedback
> > directly from their users, and conduct usability studies. I 
> think our 
> > purpose here is to provide the widest tool-set possible, that will 
> > allow authors to create help in a manner that meets the 
> needs of their users.
> 
> 
> Please carefully consider my words. Handicapped accessibility 
> is not optional. I have proposed a method of programmatically 
> addressing that issue through the process of this 
> standardization proceeding. No naysayer has proposed any 
> programmatic method of addressing the issue within the 
> context of this process.  All proposals other than mine 
> undermine the W3C VoiceXML recommendation and associated 
> standards and ignore the legal obligations of your employers 
> and customers.
> 
> From my perspective, what you're describing is an educational 
> issue, not
> > a "tools" issue.
> 
> 
> You apparently confuse whose education is under discussion. 
> It is a tools issue. As only a partial solution, many 
> accessibility markup issues could be enforced by validating 
> input against a schema during an XML transformation.
> E.g., the Bitflux and Kupu web app editors validate against a 
> RelaxNG schema, BFE in near real-time and Kupu upon page 
> save. Neither will allow a page to be saved unless XHTML is valid.
> 
> An implementation of this example that is demonstrably 
> feasible would be for this proposed standard to require that 
> implementations must validate any HTML or XHTML input files 
> for <alt> tags being present, validly formatted, and occupied 
> by text for each instance of a graphic image in a file. If 
> the validation fails the process aborts.  There are a number 
> of validators around the Web including those provided by the 
> W3C. Similar markup validation could be required for all 
> other formats converted to Help files via this standard's XML.
> 
> XML standards normally require validation and compliance. 
> That is one of the strengths of XML.
> 
> Similar validation requirements could block Help authors from 
> converting files without valid VoiceXML file navigation markup.
> 
> We are not talking rocket science here, as some say. All you 
> have to do is to cross every toy off your list for which you 
> can't up with an accessibility solution. Mankind managed 
> somehow to survive and flourish before bit-mapped computer 
> screens came along.
> 
> Perhaps someone might explain to me the logic behind making 
> it easy for Help authors to write non-accessible Help files 
> and why that is better than making it difficult. In every 
> office system I designed, I tried to make doing things the 
> right way the easiest way. I truly do not understand where 
> you people are coming from.
> 
> --Marbux
>