Re: Looking at an a11y extension for magnifiers

Charles Pritchard:
>
> Consider the HTML Canvas tag -- currently, there's no way to "hide"
> the css canvas tag but "show" its subtree / shadow dom.
>

But I think, in the HTML5 draft is already mentioned, that one
should not use it, if it matters (if it provides some kind of relevant
content) - therefore it should be no problem, if the element is ignored
completely, if script interpretation is not available (for example I
have switched off script interpretation for any unknown page -
and of course, if the page does not work, it will remain unknown ;o)

> While, obviously, this can be handled programatically,
> there are cases where perhaps it'd be nicer if the UA could simply
> initiate a CSS override, as is done when printing.

Hmm, CSS (and scripting) can be considered to be only decorative,
it does not contribute to the content of a page per definition ... ;o)
Therefore it should be no problem to ignore it, to get the 'true'
content of a document ...


>
> Print preview in black-white is a good example of an alternate view, per
> color rules:
> http://cita.rehab.uiuc.edu/presentations/guidelines/slide15.html
> "Ensure that all information conveyed with color is also available
> without color, for example from context or markup."
>

Markup - does it mean for SVG to use only presentation attributes?
Then the colour information is still available, not lost, but of course,
this might get interesting for printed pages - how to conserve meta
information and attribute values?
And of course, typically colour in SVG graphics contains a lot of
information, often not possible to get a meaningful alternative
other than text - similar is true for animation (we can consider
CSS animations or transitions as decorative, but declarative
SMIL animation can contain relevant information). The only
meaningful alternative will be typically text for a static presentation
as something printed on paper. For some other applications it
might be sufficient already to provide a snapshot time (SVG tiny 1.2).


> > For many shapes it is not possible to provide simpler
> > shapes. If it is a named (mathematical) shape, the next
>
> For the purposes of driving a screen magnifier, a simpler shape may simply
> be a rectangle which encompasses the "more important" parts of the element.
>

If you have a regular polygon like a pentagram or a pentagon, I
think, a rectangle will be typically no meaningful alternative ;o)
But if the element contains a title or the a element around it
has an attribute xlink:title, this could be a more meaningful alternative.


> > 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'
>
> Keep "alternate"/"assistive" views in mind... A sleeping kitty might
> be usefully presented using only "stroke", though fill is present.
>

Typically it is a question of abstraction level. 
If the image is very realistic, it is typically realised with quite complex
paths. Simpler paths mean typically a higher abstraction level, that
requires more intellectual capabilities. 
Whatever you do - there will be still some people it will get less
accessible. Even with text - if someone does not understand
the language, this is suboptimal too - we all know, that automatic
translation does not really work yet ...

Having this in mind, for an author it is the question, how much
additional work will be typically acceptable - ok, for the majority
this will be close to zero anyway, but if alternatives can be
realised with a benefit for many/most people, this might get
interesting for much more authors, if this means not too much
additional work.

Because simplification typically means more abstraction, such
a simplification/abstraction will be an intellectual challenge for many
authors not familiar with concepts of abstract arts or how to
increase the abstraction level without removing the intended meaning.  
Presumably it is not very realistic to assume, that many authors will
manage such an additional abstraction. Most of them will be happy
to get one graphical representation of their ideas - and of course
many will have problem to present their graphical ideas as text
as well, even if they want to.

The main work might be to provide practical suggestions, how
to realise alternatives at all, not just to define some attributes
or mechanisms to indicate a relation to such an alternative
presentation.

> It might also be presented differently when used as an icon. I don't
> mean to
> take that line of thought too far, or distract the conversation, as that
> later concept
> is quite similar to "hinting" from the font world.
>
> And a sleeping kitty might have markup describing the color relationships,
> so that, if color is not available, a pattern may be used to distinguish
> the fill areas.

This is tpically the case, if presentation attributes are used for fill and 
stroke. I think, there are generic algorithms to convert colors into 
grayscale-pattern, at least my laser printers had no problem with this 
the past 20 years ;o)

...
>
> > 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).
>
> The aria described by and labeled by semantics can at least "point" to
> RDF content,
> and the RDF content could still include text alternatives; I'd like to
> see how far we
> can get with existing semantics.


Well, because the HTML5 WG was not very motivated to add more
semantically relevant elements, I created this:
http://purl.oclc.org/net/hoffmann/lml/ 

But this is only about text.
For about 25-30 years I'm very interested in combinations of text and
graphics, I was very exited to hear about markup language both
for text and graphics and how this helps to provide alternative
representations of ideas.
Because I have a gallery with abstract arts, I had already discussions
on how provide alternatives concerning accessibility. This was one
motivation to switch from PNG to SVG. But often it turns out, that
the (text) alternative finally becomes an own piece of art, additionally
to the graphical presentation, not alternatively. It has its own ideas,
and often both are pretty useful for the audience to understand at all
(or to enjoy).



>
> Most of ARIA is about interactive widgets, of which, generally, the cat
> is not,
> unless that cat is intended for clicking, and/or petting. 

Sure, typically the next step is to allow to push the rocking chair 
with a mouseover (nice event for this cat  example ;o) to get an excited 
cat or to activate a nasty dog to get some action ;o)

What happens after one event can be pretty complex, a whole
story as text alternative for some declarative animation started
with one user interaction. Do you really think, many authors will be
able provide simpler graphical alternatives? - even a text alternative
requires already some literary skills ...

> In which case, 
> there is a wealth of vocabulary it (or its individual kitty parts) may
> be marked up with.
> http://www.w3.org/TR/wai-aria/roles#document_structure_roles
>
> > - problem of cloning:
>
> ...
>
> >    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
>
> This is handled by role="presentation". You're correct, the author
> should take care that roles and attributes are not copied in the clone
> unnecessarily.

On the other hand - the author cannot know, which leaf is chosen 
by the user to get some information on what it is. This happens, if
the user wants only additional help on demand, for example to
get an alternative text view of a subtree of the documents from a 
context menu.
Therefore the information should be available from any clone,
just something like the screenreader or the alternative presentation
as text should not repeat it. If things are cloned, the author provided
the information only once, on the original element, that is cloned.
This seems to be ok. Alternatively of course the author can provide
a text alternative only with title, desc, meta for the root svg or for
a g-element containing the complete tree, explaining that the complex
structure is a tree with lots of leafs.
Authors have to learn to be clever here and user agents have to learn
how to manage content from less clever authors anyway ;o)

>
> Cloning is a bit of a painful issue, in my experience of svg.
>
> It would have been nice to have "accumulate" options,
> to implement immediate mode graphics.
> <circle accumulate-paint ...>
> for(i =0; i < 5;i++) {circle.x = ...; circle.y = ...;}
> (same concept as animation, but the backing bitmap buffer is not cleared).
> Obviously, only works in a scripted context or otherwise used with
> something like MathML.

MathML as alternative for the formulas?

A proposal for a more powerful method to avoid scripting with
accessibility problems and avoiding unneccessary clones, allows
to generate and structure more complex objects:
http://purl.oclc.org/net/hoffmann/rdml/


>
> This concept is of course, used a lot now, in JS libraries. And it's
> available via WebGL.
>

With scripting switched off, not available at all, therefore if it is about
relevant content, JS is no solution. Often I use PHP, but then of
course, you easily get huge and complex documents as output.


> >    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?
>
> Seems doable with current ARIA semantics.

Sure, to get authors to do this, at least one has to provide meaningful
examples, how to use in such cases to avoid complex problems for 
screenreaders and other variants to present text alternatives.

>
> > - 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
>
> This one is handled by ARIA semantics.
> e.g. "aria-owns.. Identifies an element (or elements) in order to define
> a visual, functional, or contextual parent/child relationship between
> DOM elements where the DOM hierarchy cannot be used to represent the
> relationship. See related aria-controls."

This sounds interesting.
Good examples might help authors to use this for SVG...

>
> > - 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,
>
> ...  role="math" is underwhelming, but it gives a precedent for some of
> this.
>
> >    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.
>
> Well, at least we've got HTML5+SVG, where scripting works fine for
> generating
> path data from content.

To use scripting for something like this is surely suboptimal, if it
matters as content.
One needs a declarative method for meaningful content:
http://purl.oclc.org/net/hoffmann/rdml/


>
> Does the <foreignObject> concept work here -- for embedding the
> underlying raw data in the document?

What is in foreignObject is typically intended to be directly presented, 
not as alternative or as a resource. The raw data can be considered
as some meta information for the graphics, or the graphics as one
alternative graphical representation of such data. But of course, if
you need to work with the data, you need the data, not the graphical
presentation, but if it is simple to manipulate the data for another
graphical presentation, it helps to understand the numerical data.
In this case, the graphical representations are more the assistive
technologies to understand, what the numbers mean
(I talked already with someone, who was able to imagine the
meaning of one sheet of paper with numerical data directly, but
this requires a lot of experience - with some limitations I can do
this for example for differential cross sections of atomic collisions, but
for most other stuff, numbers remain numbers without a graphical
representation and further explanations ;o)

> That is, provided proper ARIA roles are used to associate the related
> content.

Sure, to indicate the relation between the data and a graphical
presentation is relatively simple in SVG+RDF(a), more interesting would
be to be able to provide information, how to generate the graphical
presentation completely from the data.
For example the program grace I typically use has this functionality,
that the numbers remain the same, but the documents describe,
how to present them. To have this in SVG would turn SVG to
some assistive technology to understand huge amounts of numerical
data ;o) And obviously, one could realise acoustical presentations
as well for many data with almost the same simple method - maybe
even tactile or aromatic presentations, if one has a device for such
presentations ('your last experimental results smell really adventurously -
you should do it once more to reproduce.' ;o).


Olaf

Received on Friday, 22 April 2011 16:06:33 UTC