SVG A11y TF teleconf -- 30 Jan 2015

<fesch> rich first item is SVG mappings

<LJWatson> scribe: LJWatson

SVG Accessibility API Mappings

RS: Have made most updates.
... Still issues with mapping to none. Need to be handled differently for SVG.
... Problem with generic containers. Don't agree they should be group..
... The drawing components in SVG take up memory. If they're not needed, we shouldn't impose logic in the accessibility tree.
... We could map them to none, unless an error condition (like tabindex or a role) was in effect.

ABR: In SVG 2 it says tabindex is a global attribute, butthere is a warning that an element should only be focusable if it's visually rendered.

RS: What if it isn't rendered?

ABR: We should just ignore it.

RS: Would like more time to work on these issues.

JW: Any issues you think would be straight-forward to address?
... Perhaps add notes in the spec to flag more difficult issues, then invite comment?

@Ed feel free to tweak the minutes if another term is more suitable :)

@ed or suggest an alternative term and I'll update the minutes.

JW: Could add something to the spec about tabindex and rendered elements.

ABR: We need to come up with a clear definition of which elements should not be focusable. could explain tabindex shouldn't be used unless element is rendered to the screen.

FE: Think that will confuse authors.

JW: Prefer to see it constrained to certain elements.

RS: Trying to synchronise the two DOM efforts for browsers.
... Do we need more content about this before we go to FPWD?

JW: If there's time, but wouldn't hold htings up.

FE: Would like the FPWD to go ahead.

ABR: The note is there. We can refine the language later.

FE: In the wider sense will this be discussed with HTML?

RS: It's being discussed in ARIA now, but we'll make sure it's aligned with HTML too.

RESOLUTION: The SVG TF agrees to publish a first public working draft, and pass to SVG and PF for approval.

CSUN

FE: Who is going?

<fesch> +1

<chaals> [chaals may go…]

FE: Would it be worth meeting in some form?

RS: Have asked IBM for space.

CMN: Too late to host a formal meeting. Think it's a good idea to meet. Something in the evening, be helpful to know sooner rather than later.

RS: Could people email me with evening availability.

CMN: Even if it's an informal meeting, we should let people who don't attend know what happened.

<chaals> [+1 to panel]

FE: Suggestion to have panel discussion about the future of graphics accessibility on the web.

JW: Good idea, but late to organise it.

CMN: Just get a group of people together and get a room. The sooner you tell people a time the better, can sort out other details after that.

FE: Will look into IDM room availability.
... No teleconf the week of CSUN.

ABR: FYI - Graphics conference in Toronto at end of April. Might submit a talk on SVG accessibility.

<AmeliaBR> http://libregraphicsmeeting.org/2015/call-for-participation/

Scope and work plan of Task Force

FE: Do we want to talk about the scope of the task?

CMN: Mapping is good to do. Would be concerned if it was the only thing we were doing.
... Could farm author guidance to the CG - which is currently dormant on the assumption that the TF would take over where the CG left off.
... My preference is for the TF to work on author guidance.

JW: My preference is for anything on Recc track - the taxonomy, API mappings etc.
... With constraints on time and resources, give priority to things other than authoring guidance.

ABR: Disagree about priority of Recc track documents over authoring.
... The taxonomy work is a big project and will take time, whereas authoring guidance could have an impact sooner.

FE: You think we should include authoring guidance in our scope?

ABR: Focus should be on SVG accessibility in general.
... Not separate guidance for different disabilities.

FE: But we should include it in the TF's work?

ABR: Consult with the CG but work on it in the TF.

CMN: +1 to Amelia.
... Need people willing to work on things, if we are going to claim they are actual work items. It's helpful to know who is responsible for a deliverable.
... What about authoring tools?

<richardschwerdtfeger> https://svgwg.org/svg2-draft/access.html

RS: Guidance... have section in the SVG spec on accessibility support. It's out-dated. Do we want a section in the appendix, or a separate authoring guidance doc?
... Needs revamping in either case.

ABR: There's benefit to having something in the SVG spec because people will see it.
... Could redirect through to a separate document.

RS: So a section on accessibility in the main spec?

FE: Where is the most authoring guidance given for SVG?

RS: Not in the SVG spec.
... Chaals wrote the original note.
... Could create a new authoring note. Where do we want to put it though?
... It wouldn't be normative content.

JW: Would like it in the main spec. Also reference to WCAG.

<richardschwerdtfeger> https://svgwg.org/svg2-draft/access.html

<richardschwerdtfeger> https://svgwg.org/svg2-draft/intro.html

RS: Could put something into the (non-normative) introduction?

<richardschwerdtfeger> a?

<Zakim> chaals, you wanted to suggest as well as impact, we should triage based on people available to do work. and to

CMN: Agree SVG authoring guidance should be connected to WCAG. We in the CG have concentrated expertise, can collect problems - what challenges do people face with SVG content, what are the causes of those challenges. That's the basis of authoring guidance.

<chaals> [Concrete example: in paths in the SVG spec it should say "BTW don't use this for text, use fonts. See font, and the authoring guidance]

<AmeliaBR> Scribe: AmeliaBR

fe: So to be clear, we should have hints in the main SVG spec, but we should also have a separate document?

chaals: Yes. Our existing accessibility guidance is 15 years old, we need to update that. As far as WCAG, I think we should refer to it but not be dependent on it.

RS: Yes, I think that WCAG is somewhat understaffed and we don't want to put all our eggs in one basket.

<chaals> scribe: chaals

ABR: Agree with chaals- WCAG is great and we should refer to it but this would be practical examples of how to implement the goals in SVG.

… originally on queue regarding authoring tools. Think that is a very relevant thing for SVG - there are a number of authoring tools to think of from purely graphical tools like inkscape/illustrator

… (youcan open an object and give it title/desc) - it is painful to do and author needs to know that matters, but there isn't a way to make inkscape guess what you meant…

… There are also tools creating meaningful graphics - charting tools, flowchart tools, etc, where they do have a basis for providing some of the accessibility information automatically

… That would provide a powerful way to enhance overall accessibility, but takes working with the tool creators.

FE: Right. And you need to give guidance in a form they can easily consume.

ABR: Good authoring guidance is the first step. Outreach to the semantic graphics tool developers could give a big win.

JW: +1 for importance of authoring tools.

<Zakim> AmeliaBR, you wanted to comment on authoring tools

<AmeliaBR> -AmeliaBR

[FWIW I am not really interested in focusing my effort on the accessibility API mappings, and more interested in authoring guidance than in the taxonomy work, as a general rule.]

FE: Seems there is resolution to have a broad scope.

<LJWatson> +1 to Chaals.

FE: Not sure if we have consensus for an actual authoring guidance doc or not.

JW: The scope we have covers the broad scope…

rrsaagent, bye

- DRAFT -

SVG A11y TF teleconf

30 Jan 2015

Attendees

Contents

SVG Accessibility API Mappings

CSUN

Scope and work plan of Task Force

Summary of Action Items

Scribe.perl diagnostic output