- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Mon, 22 Jun 2015 08:04:02 -0500
- To: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
- Cc: Michael Cooper <cooper@w3.org>, Fred Esch <fesch@us.ibm.com>, public-svg-a11y@w3.org
- Message-ID: <OF981994F6.832E7FFC-ON86257E6C.0045080C-86257E6C.0047C808@us.ibm.com>
Hi Amelia, Thank you for all the great work. A few comments. 1. If you want to change the definition of the "img" role because we have new roles called "symbol" then we are directing authors to do something for ARIA in HTML today. My recommendation would be that symbol be moved to the main ARIA core spec. to differentiate the two. http://rawgit.com/w3c/aria/master/aria/aria.html#img 2. The HTML Figure element is currently mapped to a "group" or panel role in platform accessibility APIs. http://www.w3.org/TR/2015/WD-html-aam-1.0-20150407/#el-figure Your definition of figure also refers to a caption. That is fine but there needs to be a distinct relationship between the caption an figure it is labelling. http://www.w3.org/TR/2015/WD-html-aam-1.0-20150407/#el-figcaption Because we are not introducing new elements that are known to be directly associated we need to be able to associate a label with the figure. We could define a figcaption role that requires that labels a figure. If we want to do this we should also consider putting it in the core ARIA spec. 3. Graphicaldoc would appear to be a superclass of chart, map, etc. and not a subclass. I see that graphical characteristics are missing from graphicaldoc. This should subclass either the "region" or the "group: roles. 4. Regarding dropping the g- that will be a non-starter unless it goes into the ARIA spec. It is possible that other taxonomies could run into naming conflicts so we have an ARIA Extension model: http://www.w3.org/WAI/PF/wiki/ARIAExtensions We already had this discussion with the ARIA digital publishing effort and this was the extension strategy that we all reached consensus on. Let's take figure for example. A figure could mean something entire different in the fashion world. We have to ensure we do not have name conflicts. So, if you would like a different vocabulary preamble, say graphics-, that makes more sense then I would be open to that but we need to avoid name collisions. Rich Rich Schwerdtfeger From: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com> To: public-svg-a11y@w3.org Cc: Michael Cooper <cooper@w3.org>, Fred Esch/Arlington/IBM@IBMUS, Richard Schwerdtfeger/Austin/IBM@IBMUS Date: 06/21/2015 03:55 PM Subject: Re: WAI-ARIA Graphics Module I've filled out the remaining role descriptions and created examples for each. Most of the examples are separate files (SVG or HTML). I embed these as objects to provide a figure showing the result of the code. Here's my current draft on rawgit, jumping straight to section 4 (Graphics Roles): https://rawgit.com/AmeliaBR/aria/aria-graphics/aria/graphics.html#roles That's a fork of the main repo under my account. I've submitted a pull request, but recommended that it be pulled as a separate branch so that the issues below can be worked on before merging into the main repo or Rich's changes. If you think that's unncecessary, merge away. Either way, whoever accepts the pull request, please reply to this message with the new URL that people should be using. Below I outline the main changes and issues up for debate. There are now six roles listed: "figure" is pretty much as we've discussed it. The description is based heavily on the HTML 5 figure element spec, with influence from the ARIA region role. The example uses an HTML figure with an SVG that has labelled sub-figures. "graphicaldoc" (graphical document) and "graphicalobject" (graphical object) represent the structured graphic / structured image category. I found that I could explain the purpose more clearly by breaking it apart into the two use cases: The graphical doc role would be for a large document section for which layout has semantic meaning. This is the role we would sub-class for chart, map, etc. The example uses a simple electrical circuit diagram The graphical object role would be for a cluster of elements that together make up a meaningful whole (but you still want the ability to navigate sub-components as accessible objects). This is the role we would sub-class for chart-axis, map-legend, etc. I specifically call out the difference from a group of distinct but related objects. The example is something fun, inspired by Chaals' brainstorming example of a child's drawing of a house. "iconbutton" is my name for the icon role. We can switch back to just "icon" if others prefer to keep it short, but I thought a more explicit role name might be helpful. I've got some short code snippet examples, but not complete embedded files. "img" is an edited version of the text from ARIA 1.1 for the img role. I've added extra sentences distinguishing an img from the other graphics roles. The main substantive change is that I've added a SHOULD statement: an image should have a complete description. This is because we now have separate roles (symbol and text) for the main use cases for images where a single alt text attribute is sufficient. I've also added an example, an HTML document with inline SVG, where each <svg> element acts as an atomic image. "symbol" is pretty much as we have discussed it. I added a sentence referencing I've got a few examples of symbols in HTML and SVG, including a re-use of the electrical circuit diagram, and an adaptation of Fred's blueprint diagram showing electrical outlets in a room (Fred: I added a door to the room. I thought a room with no windows or doors, but six electrical outlets, was a little too philosophical.) Some general / stylistic comments and remaining issues: I've used semantic linebreaks [1] within the text descriptions. Some of the existing text used automatically wrapping lines, some used hard breaks which were too long for my screen. If we can try to be consistent with breaking lines at natural phrases, it will be easier to track edits made by different users. As we discussed, I added informative notes with fallback roles after each description. I also used these fallback roles in the examples. I dropped the "g-" prefix for the role names because I found it cumbersome and confusing. Unlike the dpub roles, I don't see a purpose in calling these roles out separately. We want these roles to be integrated in with core ARIA roles like group and img. When we start creating complex chart taxonomies, then it would make sense to create a separate namespace of roles, since they would be used in specific combinations. Of course, I'm open to counter arguments. For the examples, if I was using SVG title and desc elements, I didn't add aria-labelledby and aria-describedby pointing to them (since you shouldn't need to!). This means that Internet Explorer is probably the only current browser that will present the full names and descriptions to a screen reader (even if it does so with the fallback roles). Where I've included an embedded object as a figure for an example, the object element is included inside the <pre> block that defines the example. If there is a better markup for this, please send me a link to the syntax. Or change it yourself and save me the trouble! I was not able to get the automatic cross-references to the main ARIA spec working. I'm currently just using the <rref> and <pref> shorthand markup, which creates empty links to non-existent definitions on the same page. If anyone wants to go in and fix this, please do. I haven't touched the introductory sections, since Rich was going to work on those & I didn't want to cause a merging mess. Best, Amelia [1]: http://rhodesmill.org/brandon/2012/one-sentence-per-line/
Attachments
- image/gif attachment: graycol.gif
Received on Monday, 22 June 2015 13:07:09 UTC