Re: SVG markup thoughts

Thank you Volger. That is a great perspective on Math. Automated systems
with authoring tools that auto-generate the content are more the norm.

One approach we might take is to pick a couple small instances (when we
actually have semantics) and see what the issues will be with inheritance.

One of the other challenges with roles is that you can't just rewrite the
role attribute. The author needs to delete and create a new DOM node to
change it. If, in inheritance, we propagate a role value and then the
author overrides it  by simpy writing to it we have yet another potential
issue.

Rich


Rich Schwerdtfeger



From:	Volker Sorge <v.sorge@progressiveaccess.com>
To:	Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc:	Fred Esch/Arlington/IBM@IBMUS, public-svg-a11y@w3.org
Date:	05/15/2015 06:29 AM
Subject:	Re: SVG markup thoughts



Dear All,

Personally I believe inheritance should be kept to a minimum and be the
exception rather than the rule.

As an analogy I refer to experience from working with (presentation)
MathML, where there is a
similar situation with the mstyle element, that allows to set
inheritable styles
(very much inspired by LaTeX commands like textbf etc.). Styles can be
locally
overwritten, partially overwritten, combined from different mstyle
elements,
some elements only inherit certain style attributes while ignoring
others etc.

In brief, it can be a real nightmare, in particular if one is trying to
access
elements of a MathML structure locally. I believe ultimately the same
thing
would hold for SVG. A well grouped SVG would allow one to access,
exclusively
focus on or extract subelements. Everything that is only given
implicitly, will
make life a lot more difficult for these tasks.

I appreciate the argument that authors might be going nuts if they had
to
specify the same thing over and over again. But again I would refer to
the
MathML experience, where the number of authors directly writing MathML
is
actually very low. Most is automatically generated, where it makes
little
difference if a few redundant attributes have to be added. On the other
hand,
the number of systems that have to process existing MathML is constantly
growing. And most developers complain about the horrors imposed by
elements like
mstyle.

Best,
Volker





On 2015-05-14 09:23, Richard Schwerdtfeger wrote:
> Fred, I understand the going nuts, ... but what this also means is
> that if you do the inheritance approach you also have to deal with:
>
>  - situations where you don't want it inherited
>  - overriding roles on elements that you selectively don't want to
> inherit the role.
>
>  This is extremely complicated for authors.
>
>  We would also need to restrict this to specific roles. For widgets
> this will be a disaster.
>
>  Rich
>
>  Rich Schwerdtfeger
>
>  Fred Esch---05/14/2015 09:17:59 AM---Rich, I think it is important to
> be able to inherit the semantic role from an ancestor for three rea
>
>  From: Fred Esch/Arlington/IBM
>  To: Richard Schwerdtfeger/Austin/IBM@IBMUS, <public-svg-a11y@w3.org>
>  Date: 05/14/2015 09:17 AM
>  Subject: SVG markup thoughts
>
> -------------------------
>
>  Rich,
>
>  I think it is important to be able to inherit the semantic role from
> an ancestor for three reasons. Semantic inheritance avoids bloat, it
> keeps authors from going nuts and simplifies guidance. Whenever you
> bloat your resource, products will argue against a bloated resource
> because it loads slower and takes more memory. We need to allow
> inheritance from any level of ancestor as intermediate groups are
> often generated for a change in style. For example, in the airline
> (delay) chart, the grid lines for the months are grouped by location
> of the text. These groupings are are more space saving than putting
> the attributes in each grid line and we should not discourage non
> semantic groupings.
>
>  In my markup, when groups should be part of navigation, I provide one
> (or possibly two) of - title, desc, aria- label, labeledby or
> describedby. Non semantic grouping (like the airline chart month grid
> lines for text location) don't have a title, desc, aria- label,
> labeledby or describedby and are ignored by navigation.
>
>  I am doing markup to support navigation and AT interpretation. Markup
> for media query style changes for low vision, color blind and coga
> will come later. In navigation experiments, regardless of the type of
> graphic, if you have groups that represent features, reasonable things
> happen (using a tree style navigation) when the groupings are done
> well.
>
>  So if it will be a problem to allow role attribute inheritance, then
> I suggest we create a semantic role or graphic role (g-role)
> attribute.
>
> Regards,
>
>  Fred Esch
>  Accessibility, Watson Innovations
>  AARB Complex Visualization Working Group Chair
>  W3C SVG Accessibility Task Force