Re: Comments on Authoring Tool Accessibility Guidelines 1.0

Bridie,

It may be easiest to accomplish the requirements through source editing, but
it is not necessary. In a SMIL presentation, the structure essentially
consists of a timed sequence, in which cerrtain elements may have several
paralell components. Being able to move from one point in the sequence to
another, and among paralell items (or switch elements, as the case may
be) would constitute navigation of the structure. That may be achieved by
stepping the focus along a representation of the sequence in what is
essentially tree-style navigation, without ever exposing the source (although
it is necessary to expose textual labels for the elements - titles, alt,
etc). Being able to find a particular timepoint, or a particular object by
name, would be examples of search functions. Being able to cut, copy and
paste a par element is an example of editing the structure.

With regard to conversions, when  multiple tracks are merged into a single
file it is expected that the information contained in each of those tracks is
included in the final file produced (for example captions, audio, audio
description and video tracks would all be available).

(I am downloading a copy of RealSlideShow, so we can more easily talk about
the same examples)

cheers

Charles McCN

On Tue, 23 Nov 1999, Bridie Saccocio wrote:

  Charles,
  
  Thanks for your comments.
  
  Re: adding functionality for accessibility, perhaps a specific example
  would help...these requirements seems to suggest that we would have to add
  add raw SMIL editing to our RealSlideshow product when the application
  doesn't offer raw SMIL editing for others.  Is this the case?  This doesn't
  seem reasonable.
  
  Re: converting files, how should we "preserve all accessibility
  information" when multiple video and/or audio files are merged into one
  streaming media file?  What is the expectation here?
  
  --Bridie
  
  
  At 02:49 PM 11/23/99 -0500, Charles McCathieNevile wrote:
  >Well, the feedback is always welcome ;-)
  >
  >To the specifics... (my interpretations marked with CMN)
  >
  >On Tue, 23 Nov 1999, Bridie Saccocio wrote:
  >
  >  Overall, the guidelines in Authoring Tool Accessibility Guidelines 1.0 seem
  >  reasonable and a step forward in promoting accessible content and authoring
  >  tools.  However, the specification should clarify its intent.  Is the
  >  expectation that an authoring tool should make existing functionality
  >  accessible (and generate accessible content) OR that an application should
  >  meet all spec requirements -- even when these requirements are not
  >  available for other users -- (and generate accessible content)?  It is one
  >  thing to expect that existing functionality be made accessible, but quite
  >  another to add functionality to an existing application.
  >
  >CMN Yes, we recognise that. In general it is existing functionalities that
  >need to be accessible, although there are a couple of functionalities
  >required by users with disabilities, which are brough out in guideline 7, as
  >you note below.
  >  
  >  We have a few specific questions/comments/requests-for-clarification
  >  below.
  >   Hope our feedback isn't too late to consider...
  >  
  >  --Bridie Saccocio
  >    RealNetworks, Inc.
  >  
  >  ++++++++++++++++++++++
  >  In the 1.1 checkpoint, what is meant by "conversions"?  Does this include
  >  converting one file type to another as in the case of encoding audio or
  >  video content?
  >
  >CMN Yes, it does mean converting from one file type to another.
  >  
  >  	1.2 Ensure that the tool preserves all accessibility information 
  >  	during authoring, transformations and conversions. [Priority 1] 
  >  
  >  ++++++++++++++++++++++
  >  In 7.1, who's "standards and conventions" is the authoring tool supposed to
  >  be adhering to?  Who set these standards?
  >
  >CMN There are accessibility standards for many operating systems, and there
  >are standard specifications for almost all of them. In most cases they are
  >written by the developers of the system. Some of the references provided are
  >to well-established research work which has formed the basis of many more
  >specific standards. In many cases, particularly in moving beyond simple HTMl
  >editors to more powerful or complex authoring tools, the application is also
  >a user agent, in whch case the user agent guidelines should be met.
  >  
  >  	7.1 Use all applicable operating system and accessibility standards 
  >  	and conventions (Priority 1 for standards and conventions that are 
  >  	essential to accessibility, Priority 2 for those that are important 
  >  	to accessibility, Priority 3 for those that are beneficial to
  >  accessibility). [Priority 1] 
  >  
  >  ++++++++++++++++++++++
  >  In 7.2, can an application depend on the operating system's accessibility
  >  standards?  For example, for entering text in a dialog, can an application
  >  depend on the OS to be capable of zooming in/out?
  >  
  >CMN Certainly.
  >
  >  	7.2 Allow the author to change the presentation within editing 
  >  	views without affecting the document markup. [Priority 1] 
  >  
  >  ++++++++++++++++++++++
  >  Can 7.4 - 7.6 be appended to include "to the extent that the application
  >  supports this functionality"?
  >  
  >CMN These functionalities are required by authors with certain disabilities,
  >and need to be implemented by tools. although thay can only be implemented to
  >the extent that a particular format permits (for example there is not a lot
  >of structure to a basig jpeg, but there is in an accessible movie
  >presentation or a structured vector graphic).
  >
  >  	7.4 Ensure the editing view allows navigation via the structure 
  >  	of the document in an accessible fashion. [Priority 1] 
  >  	
  >  	7.5 Enable editing of the structure of the document in an 
  >  	accessible fashion. [Priority 2] 
  >  
  >  	7.6 Allow the author to search within editing views. [Priority 2] 
  >  
  >
  >Thanks for the feedback. I hope this clarifies.
  >
  >--Charles McCathieNevile            mailto:charles@w3.org
  >phone: +1 617 258 0992   http://www.w3.org/People/Charles
  >W3C Web Accessibility Initiative    http://www.w3.org/WAI
  >MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA
  >
  >
  >
  

--Charles McCathieNevile            mailto:charles@w3.org
phone: +1 617 258 0992   http://www.w3.org/People/Charles
W3C Web Accessibility Initiative    http://www.w3.org/WAI
MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA

Received on Tuesday, 23 November 1999 17:31:02 UTC