- From: Volker Sorge <v.sorge@progressiveaccess.com>
- Date: Fri, 15 May 2015 06:28:29 -0500
- To: Richard Schwerdtfeger <schwer@us.ibm.com>
- Cc: Fred Esch <fesch@us.ibm.com>, public-svg-a11y@w3.org
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
Received on Friday, 15 May 2015 11:29:07 UTC