See also: IRC log
<scribe> scribe: AmeliaBR
[introductions from regular members]
BM: I'm accessibility consultant
at SSB Bart. Interest in SVG comes from data visualizations;
previous work focused on e-learning accessibility.
... I'm on the accessibility services team, largest team at SSB
Bart. We do testing of products, platforms, etc. We're now
seeing SVG all the time in content, particularly data
visualizations & charts.
FE: In the TF, we're currently
focusing on synching SVG with ARIA 1.1, so assistive tech &
browsers can get basic support in, not great, but we can expand
on it later to make rich graphics and charts.
... right now we're still in the crawling stage, trying to get
things universally supported.
https://www.w3.org/WAI/PF/svg-a11y-tf/track/actions/open?sort=due
<fesch> https://www.w3.org/WAI/PF/svg-a11y-tf/track/
<fesch> https://www.w3.org/WAI/PF/svg-a11y-tf/track/actions/2003
ABR: I'm making progress, but not closed yet. Should be able to do the clarifications to SVG 2 re empty title/desc (ACTION-2015)
<chaals> [I closed action-1602 with some pointers collected on the wiki: https://www.w3.org/wiki/SVG_Accessibility#Sites_with_use_case_stuff but I'd welcome more, especially from people who are generating them so we can work directly together]
RS: We've had progress on Action-2003, I've got actions to clean up main ARIA spec. We know expected behavior, need it to be clear.
<fesch> https://www.w3.org/wiki/SVG_Accessibility/Testing/Test_Assertions_with_Tables
FE: At that link is the list of
test assertions, with auto-generated tables of what that means
for each AAPI. Some redundancy. I'd like people to review &
see if there are systematic errors.
... e.g., for relationships, I just say "not empty" because I
don't know if API should report an ID, or how that is
presented.
<fesch> https://lists.w3.org/Archives/Public/public-svg-a11y/2016Mar/0043.html
FE: According to name calculation spec, ATK should use labelledby relationship, but according to Joanie this only applies to widgets with labels (see linked email)
<fesch> https://lists.w3.org/Archives/Public/public-svg-a11y/2016Mar/0041.html
FE: So they need to either split it out in the spec or change their behavior.
ABR: I was somewhat confused by the "not empty" wasn't sure what it meant, so if we can clarify that it would help. Distinguish it from string values elsewhere in the table.
FE: We could change that. All
caps or angle brackets. Any other suggestions for
clarifications welcome.
... I still need to convert these wiki tables into JSON for the
actual files for the test harness.
<fesch> https://github.com/w3c/aria/tree/master/graphics-practices
FE: I copied the ARIA practices
guide to use as a template. I edited a little bit, but haven't
changed much yet.
... If Doug or Chaals want to start hacking on this &
adding content that would be good. But we also need to decide
on overall organization.
CMN: I'm not too keen on defining this by ARIA. Most of what I want to focus on isn't directly related to ARIA.
FE: Do we want to call it something else?
CMN: General SVG Authoring Guidance
ABR: I agree. I have this on the SVG WG agenda, to ask if they mind us leading a general SVG Authoring Practices Guide.
RS: But who's contributing other SVG guidance?
ABR: I think most of the guidance will be accessibility-related. Just not all ARIA-related. E.g. keyboard, color contrast, good structure, etc.
DS: Agree that focusing on SVG general best practices is best. Many of these features, such as tooltips & good document structure, have benefits beyond accessibility. Need to focus broadly.
FE: I'd copied the existing spec
just because it was easier to get started. For admin it may
also be easier to work within the ARIA repo.
... Also need to design form. The ARIA guide works primarily
off of examples and common design patterns.
... In the Aria editors, we talked about SVG in other specs
& Cynthia Shelley asked "where is the guidance" to give
spec editors.
LW: There was something that Chaals had already started putting together on the SVG Accessibility community wiki.
FE: But that wasn't formatted up as a proper W3C spec.
<chaals> ACTION: chaals to make the scrapbook for authoring practices look like a W3C editors' draft. [recorded in http://www.w3.org/2016/03/16-svg-a11y-minutes.html#action01]
<trackbot> Created ACTION-2018 - Make the scrapbook for authoring practices look like a w3c editors' draft. [on Charles McCathie Nevile - due 2016-03-23].
LW: But that's the content, so we want to work from that and not re-start completely.
CMN: We do need to decide which document we should be collecting content in.
DS: It should be something publicly editable so we can encourage contributions.
<chaals> scratch space to turn into a draft
CMN: This is the GitHub repo we're working on. We can continue with it for now, and integrate it into a document template later.
DS: Could we maybe fork it into an official W3C repo, so that the live view can show up in a w3c.github.io page
LW: We don't have a designated repo for this task force yet.
DS: But we could do that.
FE: OK, I can drop the rough template I put together. But how are we going to integrate the standard features into the other one.
CMN: Copy over any substantive content that is relevant. For formatting, making it a W3C repo and adding useful metadata like intro and status,, I'll do that in the next few days.
<fesch> https://lists.w3.org/Archives/Public/public-svg-a11y/2016Mar/0041.html
FE: See Joanie's email. I think our only interest is to stay in sync with ARIA Core as far as how the names are computed.
<fesch> https://lists.w3.org/Archives/Public/public-svg-a11y/2016Mar/0043.html
<fesch> And what I am tossing out there is that **for the purpose of
<fesch> CR testing**, it might be worth doing so (slightly). In particular,
<fesch> testing for the computed string (like you do for ATK and IA2). The
<fesch> computed string for name and the computed string for description should
<fesch> be as per your expectations. If they are not, that means there is a bug
<fesch> in my implementation.
ABR: It is worth considering. Labelled by relationships in diagrams can be nearly as important as in form widgets.
FE: [Reading from Joanie's email]
For the purposes of CR testing, it may be worth focusing on
computed strings for testing rather than on relationships
... So she would like to give us an example as to when it is
necessary to have the relationship as well as the computed
name.
<fesch> No. I am proposing that your group EITHER provide me with a real-worlduse case in which exposure via AXTitleUIElement **in addition to theexisting computed string which is already in place as per your spec** isnecessary, OR discuss if it is possible to do your CR testing based onthe computed string.
CMN: If there are no practical requirements for the one main client (Voiceover on Mac), we may want to present it as a suggested implementation
RS: For relationships, it is more important for descriptions than for labels, so that you can navigate to full-paragraph descriptions. Also for flow-to and other relationships.
<fesch> https://lists.w3.org/Archives/Public/public-svg-a11y/2016Mar/
FE: They currently use it for widgets, but nothing else.
ABR: My reverse question is: what
functionality is derived from this relationship in form
widgets? Is that functionality something that would be useful
for labelled diagrams.
... I may need to ask Joanie that by email.
<fesch> But from the user agent and AT standpoint: If the name is correctly
<fesch> exposed via the computed name string, and if exposure as per the spec
<fesch> will not have any impact because the AT doesn't need that exposure, why
<fesch> should the user agent do unneeded extra work? "Because the spec says
<fesch> so," does not strike me as a particularly compelling reason.
FE: This is from the Core AAM
ABR: This needs to be decided for
the Core spec, but we want to make sure the graphics case
(labelled diagrams) is clearly considered.
... We can discuss more via email, but it needs to be taken up
at an AAPI meeting to change the Core spec. Fred's tests just
reflect that.
<fesch> https://lists.w3.org/Archives/Public/public-svg-a11y/2016Mar/0041.html
<fesch> NO meeting next week
DS: Let's take up this issue at next meeting in two weeks, to decide whether we want SVG-specific requirements for labelling relationships.
trackbot, end telcon
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/formatting and boilerplate text/formatting, making it a W3C repo and adding useful metadata like intro and status,/ Succeeded: s/it's easy to do later/I'll do that in the next few days/ Found Scribe: AmeliaBR Inferring ScribeNick: AmeliaBR Default Present: AmeliaBR, fesch, shepazu, Brian, Rich_Schwerdtfeger, LJWatson, chaals Present: AmeliaBR fesch shepazu Brian Rich_Schwerdtfeger LJWatson chaals Agenda: https://lists.w3.org/Archives/Public/public-svg-a11y/2016Mar/0040.html Found Date: 16 Mar 2016 Guessing minutes URL: http://www.w3.org/2016/03/16-svg-a11y-minutes.html People with action items: chaals[End of scribe.perl diagnostic output]