Minutes: January 30, 2015 WAI-PF SVG Accessibility Task Force

SVG A11y TF teleconf
30 Jan 2015

See also: IRC log
Attendees

Present
     AmeliaBR, Charu_Pandhi, Fred_Esch, Jason_White, Léonie, 
Rich_Schwerdtfeger, [IPcaller], chaals(LastHalf)
Regrets
     doug
Chair
     Fred Esch
Scribe
     LJWatson, AmeliaBR, chaals

Contents

     Topics
         SVG Accessibility API Mappings
         CSUN
         Scope and work plan of Task Force
     Summary of Action Items

<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

+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…

Received on Friday, 6 February 2015 13:58:46 UTC