Prepare new working draft (February 2018)

[AmeliaBR]

Email overview: https://lists.w3.org/Archives/Public/www-svg/2018Feb/0000.html is copied below.

I'll make separate issues for particular edits that are required before re-publication, and link them to this one.

---

Background:

The SVG-AAM spec describes how SVG elements and behavior should map to the
ARIA model and specifically to the operating system APIs that are used by
assistive technology like screen readers and voice control interfaces.

The last published update to the SVG-AAM was in September 2016:
https://www.w3.org/TR/svg-aam-1.0/

Even at that point, I had already made significant changes to the Editor's
Draft, which can be grouped into 2
categories:

• Changes to how use elements were exposed, to reflect the SVG 2 changes
  towards a shadow DOM model
• Changes to the default ARIA roles of SVG elements, to use the new
  Graphics ARIA roles instead of
  describing every SVG container element as a generic "group" and every
  graphical shape as a generic "image".

Re-publishing the SVG-AAM with these changes was dependent on work on the
Graphics-AAM, which defines how the
new Graphics ARIA roles are actually exposed in the operating system APIs.

Of course, activity on all of the above was delayed by all the issues with
SVG WG rechartering and dissolution of the SVG Accessibility Task Force.
This was compounded by my two co-editors on the ARIA side changing jobs &
eventually ending their participation in W3C activities.

In the new SVG working group charter, SVG WG has sole responsibility for
the SVG-AAM, while ARIA WG has responsibility for Graphics ARIA and
Graphics AAM.

New working drafts of Graphics ARIA and Graphics AAM were published this
week (and are probably close to last-call stage). Thanks to Joanie and
Michael at the ARIA working group for pushing that through. We'd now like
the SVG-AAM to be updated to match.

Next Steps:

The Editor's Draft needs some cleanup to reflect changes in other specs
over the past year and a half. I'd like to get that done in the next couple
weeks, prior to re-publication. I can do some, and Ian Pouncey (of the
Paciello Group) (@IanPouncey) has offered to join me as a co-editor, so hopefully we can
work out the clerical details between us.

That said: this would still be an interim working draft.

There are still open issues in the SVG-AAM (described as Editor's Notes in
the draft), specifically with respect to views, use elements, and
title/desc elements, none of which have direct equivalents in HTML.
Feedback on these points would be appreciated. Browser implementers could
start by looking at what they currently do & any complaints they've
received from users about that behavior.

The SVG-AAM now resides in its own repository, so please file any issues
here: https://github.com/w3c/svg-aam/issues

The main work remaining, however, is a full test suite (Where have we heard
that before? Oh, yes, for SVG 2, too!).

The SVG-AAM tests would use the structure in place for other ARIA specs,
since they need to test what is actually exposed in the Accessibility APIs,
not only what's in the DOM and on screen. For an idea of what that looks
like, you can look at the tests for the Graphics ARIA & AAM:

• Test folder in WPT
• Summary of test results

The SVG-AAM tests would need to be much more extensive, covering all SVG
elements (to be sure the default roles are correctly mapped, and role
restrictions are respected), plus accessible name and descriptions, and
also correct handling of error cases & other special behavior like use
elements.

There were some preliminary tests created based on the previous SVG-AAM
draft; these all need to be updated, and more tests are required. With
tests, we can hopefully work more effectively with implementers to get SVG
accessibility to a consistent level, and to come to decisions about the
remaining spec issues.

---

[AmeliaBR]

SVG working group teleconference, 5 February 2018, resolved

resolution: publish an updated working draft, pending edits

@svgeesus has offered to help with the W3C publication process, we will aim for publication Feb 15.

[AmeliaBR]

I'll make separate issues for particular edits that are required before re-publication, and link them to this one.

So much for that plan. Here's what's been done so far:

• Update the editors list and all the Editor's Draft URLs
• Various formatting fixes
• Text edits to the introductory sections
• GitHub issues and in-spec issues are mostly synchronized (one in-spec issue is actually a link to a Core-AAM issue), and in-spec issues are clearly marked as issues, not just editorial notes
• Add text related to aria-roledescription (issue Add details about aria-roledescription usage #5)
• Fix references (SVG 1.0 is not a normative reference, and links to the reference list should not replace nouns in sentences)

Still to do:

• Double-check all the references to other specs, especially the ones that quote them as informative notes (and then remove the Editor's note in 5.1.1). @IanPouncey had started on this.

• Update the Status of this Document section for the new WD, including:

  • Spec is now published solely by the SVG WG (but should there be mention of collaboration with ARIA WG?)
  • Update links & timelines re how to comment
  • Maybe update the request for feedback (but I think all the points are still relevant)

• Update the acknowledgements section (not sure to what..., but the SVG-A11y task force isn't currently active)

• Figure out why Travis is still not building my commits automatically (OK, that's less important for the WD, especially since I figured out how to do it manually, but it's still on my ToDo list)

[IanPouncey]

@AmeliaBR, I've committed extensive changes to the link-audit branch. There are some outstanding changes that need to be made, some dependent on changes to other documents (see the commit, referenced above); do you have any input or preference on the remaining changes?

[AmeliaBR]

Hi Ian! I was meaning to check in with you today, so it's great to see this.

I'll take a look at your specific changes later. Re your outstanding issues:

"Normative" and "Informative" definitions do not appear in Important
Terms section, and therefore the links do not work.

I can fix this. I was frustrated because it was including definitions that we don't need, so went through and deleted a bunch. But it turns out that the correct way to do this was just to add an attribute on the include statement, which triggers a script to do it properly. I did add the attribute, but now I need to sync the terms file with the shared repo again.

#issue-2 link in A.2 Issue Summary only works if mapping table is in
table view or the textPath details element is expanded.

Not sure if I can fix the cross link into the collapsible table. But I could move the full issue definition to after the table, and then just do a short note for tspan like I have for textPath, linking down to the full issue.

Links to core-aam mapping table don't work, as all IDs on the summary
elements are 'undefined', and the details elements don't open
automatically. Suggest linking to ARIA draft, i.e.
https://w3c.github.io/aria/#link instead of
https://w3c.github.io/core-aam/#role-map-link

The Core-AAM issue is more annoying. We are specifically linking to the mapping as a normative reference, so I don't want to switch to linking just to ARIA. Might need to file an issue on that spec, to figure out why their entries don't auto-expand anymore.

[AmeliaBR]

Ok, merged & deleted your branch, @IanPouncey, and synced the common files with aria-common again.

ReSpec is now giving me the warning:

[core-aam-1.1] is referenced in 2 ways: ('CORE-AAM', 'CORE-AAM-1.1'). This causes duplicate entries in the References section.

The longer version is in the common terms.html file. I'll edit it here, then make a PR on aria-common to match.

I'll also fix the issue with the issue link, and remove the now-outdated Editor's note about updating cross-references, then run a build to update the Editor's Draft.

Then I need to see if how much of the Status of the Document section can be replaced with ReSpec boilerplate, and how much I need to update myself.

[AmeliaBR]

With bcc5ef9, I think I can check off the rest of my ToDo list. (Except I'm still not getting automatic Travis builds)

I believe the next step is to create a branch for the WD & start running validation / pubcheck.

@liamquin / @svgeesus, are you able to take it from here, or do you need more from us?

[svgeesus]

Hi @AmeliaBR what we need to publish a new WD is a spec with no broken links, and with an up to date changes section relative to the last /TR publication.

Open issues are no problem at this stage.

[svgeesus]

I see a few issues reported by the pubrules checker:

[AmeliaBR]

@svgeesus

Thanks Chris, I'll take a look at those results. I assume some of them will get fixed by ReSpec when switching from an ED to a WD build, is there any way to test that? I.e., can I create a branch & then point the checker to the rawgit URL?

For broken links, is broken hashes (i.e, the page works but the target isn't found) a deal-breaker? Because then this issue is going to hold up republication: #10

[svgeesus]

Yes, ignore the ones about ED to WD because those will fix themselves.

Broken fragments are a problem, yes. So that rogue script needs to be fixed.

[AmeliaBR]

I've created a WD-April-2018 branch.

with an up to date changes section relative to the last /TR publication.

I've got a prose summary of changes in the "Status of the Document" section. Is that sufficient? ReSpec also inserts a link to the commit history.

For pubrules checking, I'm saving the ReSpec snapshot as a separate file in the same branch. View via RawGit.

Currently, the remaining validation issues are:

• Broken target links within the spec and to Core-AAM, HTML-AAM, and Graphics-AAM: all caused by that "rogue script" (Mapping tables script is creating id="undefined" on summary elements aria-common#7).

• HTML validation problems caused by another ARIA common script (restrictReferences leaves behind extra empty <dt> elements aria-common#8)

• A dead link caused by the fact that ReSpec is still inserting an outdated link to AXAPI/NSAccessibility, despite the fact that SpecRef was updated last July; not sure whether that's a ReSpec bug or a SpecRef bug, so I haven't filed it anywhere yet.

• The PubRules checker thinks that SVG working group specs should use http://www.w3.org/Graphics/SVG/WG/ as the working group website, but that URL now just redirects to the SVG wiki, so the link checker had advised me to replace it with the final URL, which I did. Which is the kind of circular validation error that I'm going to leave up to my friendly neighbourhood W3C staff member to sort out.

I have listed the WD publication date as this Thursday, but since some of the validation errors depend on fixing scripts and then republishing other specs, that may be a bit optimistic.

If anyone has time to take a look at the linked aria-common issues, that would be very helpful in getting this spec published. I do not have time to do any more spec work this month!

---

For any other fixes, please

• make the fix in the master branch / editor's draft
• manually trigger a Travis build to update gh-pages (since it isn't doing it automatically): use the "trigger build" link in the "more options" drop-down
• merge the fix into the WD branch
• open the WD branch's index.html, use the ReSpec export-as-html, and save the result over index-snapshot.html & commit

[AmeliaBR]

This WD was published in May 2018: https://www.w3.org/TR/2018/WD-svg-aam-1.0-20180510/