- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Fri, 22 Apr 2011 17:05:58 +0100
- To: Charles Pritchard <chuck@jumis.com>, www-svg@w3.org
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