W3C home > Mailing lists > Public > public-aria-editors@w3.org > April 2018

Re: SVG AAM and mpping table script

From: Michael Cooper <cooper@w3.org>
Date: Thu, 12 Apr 2018 21:35:57 -0400
To: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
Cc: "Liam R. E. Quin" <liam@w3.org>, ARIA Editors <public-aria-editors@w3.org>
Message-ID: <9fd60c8c-7283-58bd-5d0c-9686a029156d@w3.org>
On 12/04/2018 8:45 PM, Amelia Bellamy-Royds wrote:
> > the fix is to activate the "View as a single table" button for each 
> table before saving a snapshot from Respec.
> How feasible is it to get Core-AAM,
First, what are the broken links you have to Core-AAM? I just checked 
Core-AAM and it seems I did apply the fix when publishing, so the ids 
are there on <tr>s. And I just checked SVG-AAM in the master branch 
(using a Respec snapshot) and don't find broken links to Core-AAM (nor 
to the others).

If there is a broken link that is the result of a publication fault, I 
can ask the webmaster for permission to fix. If the fix is beyond what 
we are allowed to do in place for a Recommendation, it would have to 
wait for a First Public Working Draft of Core-AAM 1.2. That might happen 
in the next few months but I can't really say more specifically right now.
That's maintained by Web Platform, so you'd have to ask them. I expect 
they'd be willing to publish a new snapshot of a WD.
> and Graphics-AAM
I wouldn't want to touch a Candidate Recommendation (though I can ask 
the webmaster for permission to fix, as for Core-AAM). We plan to 
transition to Proposed Recommendation soon. I do see that in this one I 
forgot to apply the workaround when making the snapshot, which is a bit 
surprising since a broken internal link report generally reminds me. 
But, I don't see broken links to this from my own link check of SVG-AAM.
> all republished with that fix?  Because a WD build of SVG-AAM has 
> broken links to the TR versions of all three, as well as the broken 
> internal links.
> My guess is that republishing three specs is enough of a bother that 
> it's probably worth fixing the JS code first. But then, I haven't done 
> a review of the code to identify the problem.
As far as I can tell when I looked at this, it's a "feature" not a "bug" 
that the script removes the IDs, as part of changing the table to a set 
of twistie ties. I don't know if it's inherently necessary to do it that 
way, but if it is, the only script fix would be to get Respec to disable 
that script or activate the "view as table" buttons first when exporting 
a snapshot. Which I imagine is possible but beyond my current skills. If 
I ever find I have time for a deep dive into ARIA maintenance scripts I 
was going to look into this, but it's really out of my skill set and not 
front burner unfortunately, I just deal with the workaround (which I 
obviously need some system to ensure I remember to use).

> ~ Amelia
> On 12 April 2018 at 18:01, Michael Cooper <cooper@w3.org 
> <mailto:cooper@w3.org>> wrote:
>     If this is the problem I'm aware of, the fix is to activate the
>     "View as a single table" button for each table before saving a
>     snapshot from Respec.
>     This is of course not ideal. I don't know if it's possible to
>     adjust the script to not require this workaround. I'll put on
>     editors' agenda to discuss, though we will only make progress if
>     someone knowledgeable about the script attends. Otherwise
>     continuing discussion on the issue you referenced seems to make
>     sense. Sorry I hadn't seen that issue before - GitHub doesn't
>     reliably notify me of new issues filed even though it's set to.
>     Michael
>     On 12/04/2018 7:44 PM, Liam R. E. Quin wrote:
>>     SVG AAM is blocked in pubrules because of a script,
>>     mapping-tables.js, that seems to be breaking links
>>     https://github.com/w3c/aria-common/issues/7
>>     <https://github.com/w3c/aria-common/issues/7>
>>     Could this be on an agenda? Or should i dive in and try and fix the
>>     JavaScript?
>>     or is this the wrong list?
>>     Thanks!
>>     Liam
Received on Friday, 13 April 2018 01:36:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:59:22 UTC