Protocols and Formats Working Group Teleconference -- 26 Jun 2015

<trackbot> Date: 26 June 2015

<richardschwerdtfeger> Meeting: SVG Accessibility Task Force

<richardschwerdtfeger> https://lists.w3.org/Archives/Public/public-svg-a11y/2015Jun/0034.html

<richardschwerdtfeger> scribeNick: Rich

<richardschwerdtfeger> RESOLUTION: Next scheduled meeting is July 10

What can we do in time for SVG 2 (Q1 2016)?

<jasonjgw> Rich raises the question of scope given the likely qa-2016 time-frame for completion of SVG 2.

<richardschwerdtfeger> scribeNick: jasonjgw

Doug raises the question of how much can be done during this period to get implementations. Example, connectors, which can be specified easily but implementations are a different matter.

Doug is willing to improve the Connectors spec, which is needed as a prerequisite for implementations.

Amelia notes that connectors are not just an accessibility solution; they also affect the visual display and a polyfill should be possible - including one with aria-flowto for the accessibility.

Doug has a JavaScript library.

Amelia suggests a polyfill (and use thereof) as encouragement for "native" implementation.

Doug supports the idea.

Rich notes the need for an accessibility mapping for Connectors.

Amelia notes that CR for SVG 2 shouldn't be of long duration since the SVG working group has been actively removing features that aren't receiving implementation uptake.

Rich notes the importance of completing ARIA 1.1 and addressing tabindex.

Rich raises the question whether we want to develop the new navigation model in this time period.

Amelia suggests leaving room for it, but concentrating on the basic roles and taxonomy development.

Responding to Fred, Rich says it's a question of time/availability with regard to possibly creating a polyfill for it.

Rich proposes that keyboard accessibility, role semantics and connectors are the key considerations for SVG 2.

Amelia clarifies that keyboard access is a question of tabindex and scripted focus control.

Rich reiterates the importance of scripted focus control.

Responding to a question by Rich, Amelia notes that layout has semantic significance in a graphical document. Besides this, it's a matter of ensuring that anything can be focusable even if it lacks a tabindex attribute. This is already in place for widgets but it needs to extend to navigation of graphical components to explore content.

Amelia notes CSSUI in this context.

Doug offers to re-establish our engagement with CSSUI development for CSSUI 4.

<richardschwerdtfeger> ACTION: Doug work with CSS to ensure that keyboard focus in CSSUI is supported for SVG2 [recorded in http://www.w3.org/2015/06/26-svg-a11y-minutes.html#action01]

<trackbot> Error finding 'Doug'. You can review and register nicknames at <https://www.w3.org/WAI/PF/Group/track/users>.

Rich notes that he is working on ARIA 1.1 with the aim of a Recommendation next year.

<richardschwerdtfeger> http://rawgit.com/w3c/aria/master/aria/graphics.html

Amelia is working on an example that demonstrates the utility of the figure role, containing multiple, complex objects.

Rich suggests giving the entire SVG document a figure role, to which Amelia indicates an intention to demonstrate a number of points in this example.

Rich asks whether anything new needs to be included in the main ARIA specification.

Amelia: the changes made to the image role would distinguish it from the roles proposed for SVG - distinguishing it from symbol and from the ARIA 1.1 text role.

Amelia clarifies that if the image can be described by substituting a simple word or phrase then "text" or "symbol" would be more appropriate.

Rich puts it by saying that an image with a simple alternative should really be a symbol - according to his understanding of Amelia's point.

Rich proposes to take this up with the ARIA task force (soon to be working group).

He notes this would need to be discussed in authoring practices. It might take a long time for this change to be adopted.

In the context of SVG, we can recommend that authors use the symbol role in such cases.

Rich: it's important to distinguish this from the case where we want clearly to articulate the different parts of the drawing.

Fred suggests that in our document we should refer to the image role and cite the ARIA core spec.

Amelia suggests an informative reference in this case.

Amelia also notes that in the SVG spec, informative references are made to elements defined normatively elsewhere.

<richardschwerdtfeger> ACTION: Amelia modify the img role definition in the graphics.html file to reference the ARIA 1.1 spec. as the definitive role. [recorded in http://www.w3.org/2015/06/26-svg-a11y-minutes.html#action02]

<trackbot> Error finding 'Amelia'. You can review and register nicknames at <https://www.w3.org/WAI/PF/Group/track/users>.

Rich is satisfied with the actual definition of the figure role notwithstanding issues with the example.

Rich is contemplating moving figure into the ARIA core spec or having HTML refer to the graphics module in respect of the mapping for the figure element.

<richardschwerdtfeger> ACTION: Rich get with ARIA Task force and Steve Faulkner to see if <figure> can reference the graphics spec. or move it to ARIA as a region subclass [recorded in http://www.w3.org/2015/06/26-svg-a11y-minutes.html#action03]

<trackbot> Created ACTION-1663 - Get with aria task force and steve faulkner to see if <figure> can reference the graphics spec. or move it to aria as a region subclass [on Richard Schwerdtfeger - due 2015-07-03].

Responding to a question by Rich, Amelia maintains that the graphical document role defines the content, unlike figure. Given an HTML figure element with an SVG inside it, the SVG document would be the graphical document and have this role, whereas the figure element would have the figure role.

Doug: figure could be a table - it doesn't have to be graphical.

This accords with the tradition of scientific literature.

Rich suggests graphicaldoc should be a subclass of region; Amelia suggests subclass of document instead.

Amelia raises the concern that a subclass of region would appear in a table of contents/navigation view.

Fred asks how the graphicaldoc relates to a view, e.g., side view, top view etc.

Amelia notes that inside a graphicaldoc, layout is relevant, several of which might occur in a figure, where the layout of those graphical documents within the figure is not important.

<richardschwerdtfeger> https://rawgit.com/w3c/aria/master/aria/aria.html#document

Rich notes that a document is content rather than a Web application - that is, an AT would use browsing navigation in this case.

Amelia: grphical document should encourage navigation and there may be special navigation modes for graphical documents.

Amelia notes it may be better to regard this as a subclass of structure rather than document.

Rich calls for objections.

Fred isn't clear whether it's equivalent to what's traditionally called a view.

Amelia suggests a view is a very specific example of something that would qualify as a graphical document.

Amelia: layout within the views is important, hence each is a graphical document, but laout of the entire figure containing the views, i.e., placemenet of the views, is less important, so it would be a figure with component graphical documents.

Rich offers to fix the ontology.

<richardschwerdtfeger> ACTION: Rich change the inheritence in role=“graphicaldoc” from document to structure [recorded in http://www.w3.org/2015/06/26-svg-a11y-minutes.html#action04]

<trackbot> Created ACTION-1664 - Change the inheritence in role=“graphicaldoc” from document to structure [on Richard Schwerdtfeger - due 2015-07-03].

<richardschwerdtfeger> A graphical document contains complex content that a user should be able to explore. Similar to document, the graphical document may contain interactive widgets, but is not itself interactive. User agents may intercept user input for the purposes of navigation. A graphicaldoc is distinct from other documents in that the visual layout of the content has semantic meaning. Navigation methods may take this into consideration.

Amelia thinks application, document and graphical document are semantically related, though not inheriting from the same superclass role.

Amelia introduces the definition of graphical object.

Fred notes that a stack in a stack bar chart would be a good example.

Rich asks whether graphical object should be used as a default rather than group in many instances in the SVG spec.

Amelia has proposed that most elements default to symbol/image. It's a semantic distinction whether to use graphical object or group.

Example: image of a house - the house is a graphical object, but "window" would be a group, where there are multiple windows.

Amelia isn't sure that graphical object would be a default role for SVG elements but it would be widely used in the chart taxonomy.

Amelia suggests that the g element should have a default role of group.

Amelia: for an SVG element, we could use graphicalobject or graphicaldocument as the default role.

Rich notes the need for prefixes of all the names in the graphics taxonomy module.

Amelia notes it needs to be mnemonic, therefore suggesting graph-*.

Doug notes difficulties - graph has specific meaning.

Doug suggests graphics-*.

Rich agrees that this makes sense and calls for objections to using graphics-.

<richardschwerdtfeger> RESOLUTION: Vocabulary prefix will be graphics-

<richardschwerdtfeger> ACTION: Rich change roles to have graphics- as the prefix [recorded in http://www.w3.org/2015/06/26-svg-a11y-minutes.html#action05]

<trackbot> Created ACTION-1665 - Change roles to have graphics- as the prefix [on Richard Schwerdtfeger - due 2015-07-03].

Icon: icon role. He expects resistance to having an icon role distinct from button.

Amelia notes the value of having a role that matches commonly used terminology, including documentation.

Rich: cognitive task force requires task-based attributes, e.g., this is always the help button or submit button, so the UI can be styled uniformly for someone with a cognitive disability. We can leave this proposal (of an icon role) in the graphics spec, but he notes the relevance of the cognitive task force work.

<richardschwerdtfeger> ACTION: Rich Take iconbutton role to the ARIA task force for further discussion [recorded in http://www.w3.org/2015/06/26-svg-a11y-minutes.html#action06]

<trackbot> Created ACTION-1666 - Take iconbutton role to the aria task force for further discussion [on Richard Schwerdtfeger - due 2015-07-03].

Amelia is not necessarily committed to it but thinks it should undergo public review.

Rich thinks we need to start working on the chart taxonomy.

Fred agrees to take this up while Rich is on vacation.

- DRAFT -

Protocols and Formats Working Group Teleconference

26 Jun 2015

Attendees

Contents

What can we do in time for SVG 2 (Q1 2016)?

Summary of Action Items

Scribe.perl diagnostic output