See also: IRC log
<fesch> regrets Leone
<scribe> scribe: AmeliaBR
FE: Presentation is not a "golden hammer", but we have some flexibility when its native features.
ABR: Yes, ARIA says global aria attributes cancel out role=none/presentation, but nothing currently about native alternative text.
<joanie> https://rawgit.com/w3c/aria/master/svg-aam/svg-aam.html#include_elements
<Zakim> joanie, you wanted to ask if there is a corresponding SVG AAM spec change in order
ABR: presentation role takes precedence over native semantics, but global aria attributes and focus can cancel it
JD: Looking at the current spec, it currently does not have that exception. 5.1.2 as currently stated does not agree with the consensus from the discussion.
ABR: Yes, that section needs to be re-written based on the discussion from yesterday to explain how to deal with conflicts. So we can integrate whatever we decide today.
DS: I don't have strong
preference either way, but whatever decision needs to be stated
in a way that indicates its an open issue. Keep dialogue open
for feedback from authors & implementers.
... Don't know what works in practice, need feedback from a
wider audience.
<Zakim> joanie, you wanted to add that if there is nothing special is done, the default WebKit code does not include it.
JD: I discovered this after
removing the code I'd recently added & re-running tests. I
was surprised the <title> didn't override
role=presentation based on current behavior.
... So I think it's best to do it this way: let presentation
take control. Don't ask implementers to change things and then
take it out.
FE: I had originally wanted a "golden hammer" to make it easy for authors. But just giving it power over title & desc doesn't really help authors because it doesn't have power elsewhere.
DS: If you do something the right
way, with native semantics, it should work. But I don't know if
there are any use cases for having a title and a
role=presentation.
... Could there be a use to have a drill-down feature?
FE: We can discuss this more on the list, maybe?
ABR: To follow on Doug's comment, I wouldn't want to overload role=presentation for added features like drill-down. Treat this as an authoring conflict, while recognizing that it is something that may come up when authors are using <title> for its tooltip effects.
DS: We can resolve for now, but agree to add it as an issue in the spec.
JD: Fred & I have been
working through the tests, but I don't know if anyone else has
been discussing them in detail.
... In WebKit, any new feature or bugfix requires a "layout
test". So as I add the SVG-AAM features to WebKit, I've got to
add tests to match.
... I've therefore been trying to re-use Fred's tests as much
as possible.
<joanie> https://trac.webkit.org/browser/trunk/LayoutTests/accessibility/w3c-svg-name-calculation.html#L1
JD: But the layout test format is WebKit specific, and may not always match what you use for W3C in general.
JD: compare these tests. The
markup and the scripts are different, but the actual tests are
quite similar.
... I've started adding the name of the test and the test case
to the wiki. The numbers aren't always consecutive, but most of
them match up.
DS: What's your role in WebKit? How do these changes get integrated?
JD: I'm a regular contributor to WebKit. These changes have been committed. They're not integrated in Safari yet, but they are in the core codebase.
JD: I haven't yet added the links to results in the wiki, but here are them (first link on Mac, 2nd on Linux)
JD: The test output is the expected name, and then all the WebKit-y names for the different API fields. Linux uses different field names, but the bug testing uses the Apple names, so need to mentally translate.
JD: compare with Fred's table of
the expected output on each platform. This is based on what you
would see if you manually ran the accessibility inspector. In
Linux, the names are different but the values are the
same.
... The benefit of the WebKit layout tests is that they are run
automatically every time the code is changed.
... If this is acceptable to meet the W3C CR testing
requirements, then we don't have to do nearly as much manual
testing.
DS: Automated testing is great. Need to confirm that they integrate with our test framework, but I think we've integrated tests from WebKit previously. I'll check with colleagues.
JD: As I understand,
accessibility testing can't be automated easily with the W3C
test harness, because it depends on the contents of the
accessibility tree, which is not exposed back to website
scripts.
... It would be great if you could, but I don't think you
currently can.
... We don't expose the accessible object, accessible name,
etc., to the DOM.
RS: So how is Cynthia doing it?
JD: She has her workaround, just like I do. Extra scripts with python and such. But it's not part of the W3C testing harness.
RS: So we can do it, just not with the harness?
JD: But it's preferred to have
them automated, so you don't need to open up the accessibility
inspector manually.
... Versus the WebKit layout tests run every time you build the
browser from source code.
RS: But what about a generic accessibility inspector software that uses the accessibility API to inspect?
JD: That's another option. But using the existing W3C test harness not currently an option. And if we use the accessibility API approach, then we are not re-using the WebKit layout tests.
RS: Did you create a re-usable JSON format of expected results?
JD: I did not.
FE: I create JSON as part of compiling the tables of expected results for each platform.
RS: So from this list of expected
results, you should be able to convert that to the
accessibility API calls to extract the relevant values &
relationships?
... Once you have that ability to convert the expected results
to interface tests, then we should be able to automate on any
platform. But you need those scripts.
FE: As I understand: the layout tests are good, but we're not going to be using them directly for CR. Need something comparable for all platforms.
RS: Joanie, are your tests built from the JSON using scripts?
JD: Not currently, it was a proof-of-concept thing.
FE: So we wouldn't use Joanie's tests at all?
RS: Would they be able to test all platforms?
JD: They would test Mac & Linux. And the tests are run automatically every time the software is built. So I can verify my implementations & any new changes.
RS: So the test launches the browsers, loads the files & runs all the tests internally?
JD: Yes.
RS: It would be nice if we could do that as a plug-in in Firefox.
JD: Possibly. I don't know
Firefox details. For WebKit, we have additional code that makes
all the accessibility API calls. This is important because we
don't want to test the internal accessibility layer, we need to
test the exposed values.
... I think Firefox's tests work the same as far as running
automatically at every build. But I don't know if they can
access the exposed layer in the API.
RS: I think we need to look into
this. If we can do things this way, working at the API layer
without needing to dive down to deep.
... If there's a way in Firefox to add a plug-in to access this
information, if it's exposing it, that would be useful.
JD: There's a barrier to entry
for both approaches. You need familiarity with the tools to
write the tests, but running them is straightforward.
... whether you use them for CR testing or not, I will still be
using these internally. So please don't remove that field from
the wiki.
FE: We're out of time. I also think this is an issue beyond SVG. We need coordination with the rest of ARIA.
ABR: Joanie, would you be able to keep your test suite easily updated, if Fred is able to provide eg JSON of expected results?
JD: Yes and no. Changes to layout
tests still need to be code-reviewed in WebKit. So it wouldn't
be super-fast to update.
... If changes are in logical chunks, it can happen.
ABR: It sounds like, no matter
what, we're going to need custom testing software for each
platform. But so long as they all rely on the same underlying
list of tests and expected results I think that's OK.
... but as Fred said, we need to discuss further, for ARIA
testing in general not just SVG.
JD: And maybe it will end up that the other approach is better, and the layout tests won't be used directly.
RS: I really hope we can use the plug-in approach, using the new extension model that works for both Gecko & Chrome. Although there would still need to be platform-specific code.
JD: There are lots of platform-specific complications. We can't just test the core code using the internal model.
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) Found Scribe: AmeliaBR Inferring ScribeNick: AmeliaBR Present: AmeliaBR Joanmarie_Diggs sh shepazu Rich_Schwerdtfeger Agenda: https://lists.w3.org/Archives/Public/public-svg-a11y/2016Mar/0052.html Found Date: 30 Mar 2016 Guessing minutes URL: http://www.w3.org/2016/03/30-svg-a11y-minutes.html People with action items:[End of scribe.perl diagnostic output]