Re: Looking at an a11y extension for magnifiers

On 4/19/2011 2:01 AM, Dr. Olaf Hoffmann wrote:
> 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
They are addressed by the use of text alternatives, per WCAG and in the 
US, Section 508.
But that does not mean we should simply stop there, with text alternatives.

> 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.
..
> Unfortunately many current viewers have no text alternative
> or the current presentation is only of limited use for the
I agree: presentation alternatives should be more easily accessible in 
UAs/viewers.
CSS offers a large set of tools. There's room for improvement, and I'm
sure we'll continue to see gradual improvement from the CSS family.

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

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.

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."


> 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.

> 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.

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.

Again, those may go off the topic of magnifiers, but they're on the theme
of a11y, granting authors more means to express their intent, and users
additional means to view content alternatives.

> mathematical description, it is often quite difficult
> for most people to imagine a graphical representation.
It can be quite easy, though, to enable programmatic access;
by text alternatives (prose, as you've said), and by additional references
and attribute semantics.

My current focus is on better enabling screen magnifiers and eyes-free 
touch interfaces.

> 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.

Most of ARIA is about interactive widgets, of which, generally, the cat 
is not,
unless that cat is intended for clicking, and/or petting. 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.

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.

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

>    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.

> - 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."

> - 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.

Does the <foreignObject> concept work here -- for embedding the 
underlying raw data in the document?
That is, provided proper ARIA roles are used to associate the related 
content.

Thank you for your attention to this conversation. This is a learning 
experience for me. I may
get some statements wrong -- feel free to correct / question my posts on 
or off the list.

-Charles

Received on Friday, 22 April 2011 01:17:19 UTC