Re: Looking at an a11y extension for magnifiers

On 4/22/2011 9:05 AM, Dr. Olaf Hoffmann wrote:
> 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)
It's not a problem, and scripting in a toggle is fairly easy.
It does require extra dev time, be it switching over to IE7
or using another non-canvas client, to test the fallback content.

I realize there are many ways to handle that situation,
such as just changing the name on the tag. A css solution
would be a little easier in development, compared
to the current need of browser extensions or other extra scripting.


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

Illustrations, typography and other presentational attributes
are more than decorative, to the reader.

Looking at rich internet applications:
the "content" the author expresses with an application is in the 
interaction,
it is the UI, the presentation, and the ways that presentation
relays actions to other APIs.

In that sense, presentation is very much a part
of the content the author expresses, and alternate presentations may
mean a different user experience.

Consider with media queries that there are several UI types, and 
view-mode adds
another dimension.
http://www.w3.org/TR/view-mode/



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

Output from a well-design SVG-based bar chart app may come with some 
accompanying CSS,
for non-color situations, which "@media all and (monochrome) " matches, 
so that the legend is legible.

Attention to more user interfaces, means more accessible content.

You're correct, that the color information is available via markup.

Automatic dithering can certainly do a lot with black and white media;
and a browser extension can certainly can walk through markup, and apply
other heuristics. That's what assistive technology is about, and accessible

There is a human process, of looking at the content in monochrome
to see if the information and intent is still carried, a time when new 
presentational
content may be added proactively.  For important content, intended
for wide distribution, it makes sense to take those proactive steps;

The difference in quality could be analogous to machine translation v. human
translation.

>>> 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.
Consider three elements lined in a row, a tall rectangle, a short one,
and an even smaller triangle, all of them are focusable. The screen 
magnifier
may stay zoomed-out, to the height of the tall rectangle, so the user can
toggle between all three shapes without zooming in/out; or it
may zoom-in, based on the bounding box of each individual shape.

That's really up to the author of the magnifier. But, the author of the
shape selection widget may want to convey some additional intent,
such that a zoom on the tall triangle only show half of the tall triangle,
making the other two shapes are more easily visible at that zoom level.

By using a simple shorter rectangle to capture the focus of the tall 
rectangle,
the magnifier may operate in a way that better reflects the author's intent.


>>> fitting to such an abstraction, simpler and more complex as for
...
>> Keep "alternate"/"assistive" views in mind... A sleeping kitty might
...
> 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.
There's always a tension between resources and best practices.

The Table of Contents from WCAG has several reasonable statements:
http://www.w3.org/TR/WCAG20/

As programmers, we know each one of those statements requires 
attention/resources.
It's nice to have them as guidelines, a best practices document for rich 
internet apps.

> 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.
Authors have time at their hands; making their content consumable
is part of why they're putting in energy in the first place.

The immediate benefit of making alternative text consumable is that
assistive technology can access it. Consider Google Translate;
with proper alt text, I can quickly script a browser extension,
or the site itself, to work with Google Translate, to both display
and speak the text the author is currently hovering over.

That's something, as an author, interested in reaching a wide audience,
I'm willing to put additional work into. And that work, mostly, involves
cleaning up, and better structuring my code base, so that it's flexible
enough to handle alternate text in a maintainable way.

There are corporations and individuals, under a budget, under a deadline,
where ideals for best practices meet pragmatism, and secondary ui
components break down. That's a reasonable part of development.

I've noticed in my work that sometimes we conflate best practices with 
scope creep,
and end up with uneven quality in our production. From a programming side,
managing additional abstractions has invariably led to better, more 
maintainable code.

That's a net benefit, in the long run.
> 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.

I agree -- the posts by you and Cameron on this thread, and some of mine,
are a good start on this.

WCAG 2.0 has a focus on CSS/HTML, ARIA 1.0 targets HTML4.

I'd imagine that work on SVG and HTML5 mechanisms will
be useful for future drafts of those documents.

> 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)
There are, but in cases, such as color-coded legends (per my earlier 
example),
it would help of the author would maintain additional data in the file,
via CSS and/or markup.


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

The same can be said of secondary user interfaces;
they can be more than mere "alternatives", they can add value to the piece.

I noticed, just by turning on text to speech on certain actions, I could
easily tell what a person was doing remotely, as I chatted with them
on the phone, and they went through the application.

I had decided as an author, on what should be said, and when, and
when executed, it added to the application.

I think that Google's venture into online software sales (the Google 
Chrome web store),
hit upon something similar... The applications there are often 
criticized in the reviews
for being "just a bookmark"; other users notice that the
bookmarks have alternate user interfaces, and though they may portray 
the same
content as the website, something new is added.



>> 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 ...
With magnification, the alternative paths are intended to drive the 
magnifier,
not to be seen by the user. With touch based eyes-free interfaces, the path
is intended to be slid into -- I might use a rectangle for the region over
the cats body, and a triangle for the region over the cats head,
simply to make it feel more spatially representative.

I expect that, if authors are developing widgets, using the scripting 
environment
and/or XML markup, they'll go through great lengths to develop quality 
in their work.

>>>     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
I'd imagine they could use x/y coordinates if a pointer device is used.
This is often when authors rely more on the scripting environment,
and less on a formal scene graph. It can be a bit more difficult/costly
to formalize the scene than to generate it procedurally.

> Authors have to learn to be clever here and user agents have to learn
> how to manage content from less clever authors anyway ;o)
Yes, that's it exactly.

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

Thanks for the link!

Markup proposals have really helped me when developing apps, as they 
give me a better
understanding of the abstractions involved in the problem I'm working on.

Your proposal has some similarities with the mapping section
of the InkML spec. It's also intended for raw data.

I encourage you to read through that spec.

It's more focused on device data, from say, a pen,
so it certainly goes a different direction than your proposal. But, it 
shares many concepts.



>>>     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.
You're correct.

>> 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...
I'm getting started on this.

>>>           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/
Originating the content from the scripting environment is not necessarily
a bad thing. I consider the declarative xml as a serialization
target for the scripting environment, when I develop.

I do the same with SVG at times -- drawing procedurally, then
allowing users to download the serialized copy. Typically, it's easier 
to serialize
than to implement; my svg files are usually one-way when it comes to 
editing.


>> 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
What's the alternative? RDF seems overpowered for some cases
and mixed SVG/HTML is starting to happen, now that they can more
easily co-exist in an HTML5 doc.


>> 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.
I feel the same way about sending <script> in a human readable form.

XML based markup does not necessarily make things more readable.

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

There are fun trips with LaTeX and other type-setting software,
using markup. But you really are heading right back into scripting.

The hard part is coming up with standard language that vendors agree upon,
and best practices and practical examples for authors to follow.


-Charles

Received on Monday, 25 April 2011 01:47:08 UTC