Re: Looking at an a11y extension for magnifiers

Charles Pritchard:

...
>I'm here to explore what exists, how we can make it work
>with available standards, and to see if new methods or
>attributes are needed by the AT and/or content authors.

I think, many problems are already covered by the option
to provide a text alternative, in doubt if there is a problem
with the graphics or the understanding of the graphics,
everybody should have an option in his viewer to switch
to the text alternative to get some help.
Understanding of graphics can be quite difficult for
everybody, text alternative can help everyone.
Unfortunately many current viewers have no text alternative
or the current presentation is only of limited use for the
audience, therefore it is even harder for authors to write
text alternatives - if they have no practical experience, how
text alternatives are presented, they get no practice how
to provide it in a meaningful way.

For many shapes it is not possible to provide simpler
shapes. If it is a named (mathematical) shape, the next
simpler (?) presentation is either prose or a formula or
both. Therefore simpler shapes are only an option for
objects, we have an abstraction in mind - what the author
means, has already an abstract representation in the brains
of the audience, therefore there are many (graphical) representations
fitting to such an abstraction, simpler and more complex as for
'sleeping cat in a rocking chair swinging by a gentle breeze' - 
but it is the question, if it is useful to introduce some 'simpler' 
graphical abstraction level or if the abstraction level of the
alternative text is not in general better, because we
have in mind already some abstraction to imagine the intended
graphics or szenario.
Problematic cases are representations of objects
we have not in mind - and even if we have the
mathematical description, it is often quite difficult
for most people to imagine a graphical representation.


Concerning, ARIA, role, RDF(a), accessibility and SVG 
I can see some more interesting problems:

- problem of semantics: 
  indicate semantics (of text in SVG) with role, RDF(a); 
  possible especially with attributes added in SVG tiny 1.2, 
  more difficult with RDF in meta for SVG 1.1.
  example: Indicate semantic structures like a paragraph, title, heading,
  quotation, poem (-strophe/line) etc
  in general this works as well if someone wants to indicate a group to
  represent a cat, house, named geometrical structure - at least if there 
  is a formal language available with referencable definitions for role or
  RDF(a).


- problem of cloning:
  For a text representation it is not obvious how to represent cloned objects
  (use, tref) - should the information be repeated or not in the text
  representation and at which position of source code? This might require an
  additional attribute/indication to say, which clone matters - for example on
  the use and tref element, however this does not solve the problem, that a
  used element can be reused as well - not sure how to indicate, which clone
  matters.
  But obviously it would be a pain for the audience, if for example for an IFS
  (iterated function system) of a tree, the screenreader (or whatever is used)
  would have to repeat thousands of times 'leaf' due to cloning and because
  the original 'leaf' element contains a title or desc with this information.
  Typically one should expect, that elements in the defs elements itself have
  no text representation, only the clones - or in case of animation elements,
  pattern, gradients etc, if they are referenced by other elements outside the
  defs. Not a simple task to present a meaningful text presentation of such
  structures. It is maybe simpler to be able to indicate all clones as
  meaningless for the text representation and to indicate an additional
  structure, that represents them all at once?


- problem of rendering order:
  Because the place in the source code determines the rendering order, this
  will dominate the order of objects within the source code, not what would be
  understandable for a text representation - this might require a mechanism to
  indicate, which order is useful for a text representation - not sure, how to
  do this ...
  Of course, one could use the text optimised order within the defs and
  reference all of this only with use elements for the graphical
  representation, but then there is a need to indicate, that the defs contains
  a structure adequate for a text representation. The other way would be
  possible too - to have a specific structure for the text representation
  similar to a defs containing only use elements to indicate a proper order
  for text repesentation - well maybe this is possible already with RDF within
  a meta element?


- problem of (mathematical) graphs, technical drawings etc:
  Typically the SVG presentation (path data) is pretty useless to (re)use the
  information, because the relation from raw numerical data to SVG path data
  cannot be reconstructed, information gets inaccessible for any audience,
  because everybody needs the raw data as text to use the information
  represented by the graphics.
  Solution a: Put raw data into the meta element additionally or reference
                     another file containing the information related to the
                     graphical representation (one can do this right now with
                     SVG 1.1/1.2)
  Solution b: Put raw data into the meta element and provide a mechanism to
                     generate the SVG path data from this.
        Advantage: Data are effectively reused and simple to change
                             without a need to recalculate the  graphical
                             representation.
        Disadvantage: does not work currently in SVG 1.1/1.2.





Olaf

Received on Tuesday, 19 April 2011 09:01:54 UTC