See also: IRC log
<fesch> regrets Leonie
<scribe> scribe: Brian
<fesch> https://lists.w3.org/Archives/Public/public-svg-a11y/2016May/0011.html
<AmeliaBR> https://github.com/w3c/aria/tree/svg-aam
AmeliaBR: Gotten to edits on
SVG-AAM - not quite finished up
... should have it finished up for discussion next week
... This should clear off a lot of outstanding issues on
unclear text
fesch: Hi Rich, anything for news or the agenda?
Rich: W3C allignment with IDPF
Doug: IDPF stands for
International Digital Publishing Forum
... IDPF did ePUB. There have been high level talks about a
merger partnership, something
... I think it was leaked to the press
AmeliaBR: Tim Burners-Lee made an
announcement
... this was announced day before last
Doug: Honestly, don't know the
nature of it. From what I understand W3C and IDPF are
partnering for the next generation of digital books in the W3C.
This has been in a works for the while
... Not sure what this means. No guarantee any format will
reach reccomendation
... There's some disagreement amogn staff and browsers about if
this is the right path to have one document format
... Browsers say we need to do service workers and on the fly
publishing. You don't send a book by email, you send a URL, and
they visit the URL and ask a service worker to save a copy
offline
... To me, there is a strong use case - Gov't forms, other
things - for replacing PDFs. That's my goal
... On the other side, people say PDF is part of the web.
Browsers have PDF viewers etc, we don't need something that
replaces PDF.
... I want to see a replacement for PDF because PDF documents
have a wide range of quality in the markup - for how accessible
it is
... as CSS improves we may approach a PDF replacement
Rich: PDF on mobile devices sucks. Pinching. It's better to have a web based, HTML based structure to adjust to screen size
Doug: PDF has its own ecosystem of tools and experts, Infrastructure chains. US government is a huge user of PDF
fesch: how does the DAISY consortium play into this?
richardschwerdtfeger: they
cofounded IDPF
... the ARIA structural semantics that's used came form ePUB.
Based of constructs in DAISY
fesch: any other comments?
<richardschwerdtfeger> https://etext.illinois.edu
richardschwerdtfeger: I'm going
to post a link here to a video of what they're doing with EPUB
and education
... it's nice ot have a packaged document so you can port it
around. If a browser wanted to, they could. I know they use the
Lucifox plugin to read documents
... To your point Doug, I think there's some things we can do
that would be easier to work with. It's based on XML whcih
browser vendors hate.
... I presented on this at AccessU this week
<fesch> https://github.com/w3c/aria/pull/365
Doug: Before we switch topics - I
had one more thing.
... The thing I wanted to say is, the implications of this to
accessibility are pretty large. I think Rich and I both assumed
that you all know this.
Becasue we're working on all this infrastructure for accessible data visualization. All of this work would acrue to a PDF replacement
Doug: If we can get this shift, were people are using "WEBPUB" or whatever the upcoming format would be. That would be a huge shift
fesch: that could be a huge user base for SVG?
Doug: it would. IT would be a
whole game changer - many challenges today would be moot. We
would not longer have to concentrate on making PDFs accessible.
It would take that out of the equation
... Rich, think that's a fair assessment?
richardschwerdtfeger: we talk
about html and SVG, but you have MathML in there. It's like
night and day
... the reality is, the center of all the accessibility
expertiese, the best in the world, is at W3C. It's a big
deal.
... not to levrage all the phenomial work these people have
done
... If you look at apple, if you look at their ecosystem, they
take epub. Android exports epUB, google docs export epub. We
can leveraeg the W3C and can pull that into books. It'd be
crazy not to
Doug: to your point Fred, there'd
be a big user base for SVG. If we get data visualization work
in the next year or two. If PDF is replaced by this thing, it
adds accsssibility to a wide range of use cases
... this would include government resrouces. Not just things
produced by them, but also for them
... Image accessibility, if we do this right we could sweep in
a huge changes for civic documents.
<fesch> https://github.com/w3c/aria/pull/365
<AmeliaBR> Branch as a compiled document: http://rawgit.com/w3c/aria/graphics-roles/aria/graphics.html
fesch: did people have a chance ot rad amelia's changes?
AmeliaBR: I can go over it
quickly. A lot of this is clean up
... little things like, the title was different in the title vs
what we referenced in the spec
fesch: I read it. I had but one minor word change. Does that work for folks?
<shepazu_> +1
fesch: Let her go over it, and see if we have all thinks it's good
AmeliaBR: I have a few semantic
changes. At the end of the introduction I added some more
sentences about what's different between this level one
spec
... and the roles we want to have
<AmeliaBR> http://rawgit.com/w3c/aria/graphics-roles/aria/graphics.html#introduction
AmeliaBR: I specifically
mentioned that we need these as default roles
... and that they will be useful with other WAI-ARIA. We will
in the future expand to support charts and maps
... the next section that has meaningful new text is the
section of User Agent support
... it had a cryptic sentence referring to main WAI-ARIA spec.
I added a little bit of explanation
... User Agents don't have to do anything special for ARIA
semantics, but they may. Some things they may wish to do
... next section, coevoltion of WAI-ARIA uses
... a lot of stuff that's not relevant ot this spec, widgets.
Eventually the host language will adopt that widget natively.
It's not relavent to this spec
... section on assistive technologies. This started with a
default reference to the other spec. I added some specifics for
graphics
... talking about what tpyes of changes assistive technologies
may need to make for graphics
... breaking it down to assistive tech either modifying a
graphic or breaking a graphic down entirely into text
... declaring a graphics-document may not be relveant if
breaking a document down itno text, but may be for others
... take a look if you need any wording changes. Any questions
or concerns?
<shepazu> +1
AmeliaBR: anyways, little
diversion. As i mentioned at the start, I've got work to clean
up the AAM spec
... one thing on that - if it's not too much of a change in
topic
fesch: well, before AAM
... anyone have an issue with Amelia merging the banch?
AmeliaBR: want to resolve these changeS?
shepazu: I have a lot of confidence in Amelia. I don't think it's a problem
richardschwerdtfeger: it's fine
RESOLUTION: Let Amelia merge her branch into the graphics module
fesch: you had something about AAM you want to talk about AmeliaBR ?
AmeliaBR: one of the changes to
AAM was changing the mappings to the new roles. Need to make
corresponding changes to SVG2 for that
... I was looking at the SVG2 section for that. I was wondering
if changing the mapping table from SVG2 to something that's a
little more author focused
<AmeliaBR> https://svgwg.org/svg2-draft/struct.html#implicit-aria-semantics
AmeliaBR: right now it's a long
table - a lot of which is repetitive
... 2 things, either change it so it's a direct copy of the
SVG-AAM, other option is replcae it with a more readable prose
version that's easier for authors to understand.
richardschwerdtfeger: I don't understand what's not readable for authors
AmeliaBR: it's hard to look at it at a glance a figure out the significance of all this
richardschwerdtfeger: I'm not following. What do you want to put in here?
AmeliaBR: group things by
categories. Say, "Shapes", shapes have a default role of
presentation. except in these case when they have a role of
graphics-symbol
... break it down that way. Explain why they have a default and
explain when and why users can change
richardschwerdtfeger: this is designed after HTMls - this would make something that looks different
AmeliaBR: I'll write up an example of what I'm thinking. Maybe also update this to match AAM. The other one, rewriting it the way I'm picturing it
richardschwerdtfeger: I got what you want to do. All I'm saying is it's inconsistent with what HTML is doing
fesch: HMTL has a mapping table not in the AAM?
richardschwerdtfeger: they have
all the elements in a list with their natvie host semantics.
Uou want to basically
... take a whole bunch of these that are ignored and put them
in one group?
AmeliaBR: exactly. So you can find the content and not get lost in element names
richardschwerdtfeger: I can see the value in both, but they're not done that way in HTML. Not saying no, just asking what people think
fesch: what AmeliaBR is proposing sounds like how roles are mapped. I see the value of staying with HTML, but I see the value of finding your guy in the section that tells you what you can or can't do
AmeliaBR: I'll try to come up with two branches, one to match the AAM and one sort of rewritten
fesch: are the concepts known within SVG the way you want to break it out? Filters meshparts, say? Concepts already in SVG to make groups?
AmeliaBR: for the most part they
are.
... I've added a definition of Never Rendered Elements for
things that are never mapped to anything. Or, areas wehre we
need new definitions
richardschwerdtfeger: what'll
make it a little harder. the SVG group has added or removed
elements
... it's helpful for a 1:1 comparison. It'll make it harder to
keep track of that
... I'd love to see this thing filtered or sorted
AmeliaBR: one benefit of grouping
by categories is that it's clearer is a new SVG spec adds
something to a category
... If a new spec adds a new star element, the same rules for
shapes apply. So long as it's clear we have extensbile rules
for how it should be treated with ARIA
... I'll try and get something concrete for next week.
Hopefully something out today or tomorrow
fesch: any other comments on this topic?
<fesch> https://lists.w3.org/Archives/Public/public-svg-a11y/2016May/0014.html
<shepazu> http://w3c.github.io/svgwg/specs/svg-authoring/
fesch: it came out kind of htis morning. IF people hadn't had a chance to look at let's go over the scope of the document
shepazu: I tried to make time to
do this well in advance so that you would have something to
review. No expectations you had time to review this in
detail.
... Structurally, I think you'll see this is definitely an SVG
uathoring guidlines. Not specific to Accessibility. Where there
is a topic that is important to accessibility
... first off, I lay out all the reasons auhtors should do
something they should do not including accessibility, but also
use
... for search engines, mobile, etc. Animation is another. You
want to naimate things in the correct way.
... there are lots of topics that don't have anything to do
with accessibility, that's on purpose.
... you will not I have this structure - and accessibility tip
- where I call out a specific reason to do somethign for
accessibility reasons
... especially in text and title sections. Also, navigation, I
talk a lot about accessibility
... not sure what's going on with ToC and headers, styling
seems to be weird
... there's several topics. I've mostly been working on general
things you should do for all types. Next this is specific
types, Icons, visualizations
... I'm using respec to write the spec. I'm using the native
features in respec. Will have good and bad examples of
things
... I'm trying to tackle the major accessibility issues, for a
variety of uses
<fesch> ?
shepazu: any comments?
... questions?
fesch: I started reading this. I
sort of understand where you're going with this. I had one
question on the first sentence
... it mentions it's an abastract language, what makes it
abstract?
shepazu: there are lots of
graphics specs that are area specific. Flowcharts is a specific
language. Something for schmeatics or building layouts are
specific languages
... SVG is semeantics neutral, it doesn't have specific
features like htat
AmeliaBR: I think "general" sounds better than abstract
shepazu: form my description of
the approach, does this align with expectations?
... hearing nothing I assume
... I did a perfect job.
AmeliaBR: I like your tone and your approach - building examples with not good, slightly better, best examples.
shepazu: I don't anticipate going
into that particular detail in all examples
... if there's a bad way I plan on showing the bad way, and
going into more details. And labelling the examples as good and
bad and labeling them that way
AmeliaBR: we may want a class to specifically adress this is a BAD example
fesch: it looks like a quick start guide. You get a little bit of everything and see how you do everything
shepazu: it's designed to be a
recipe book. For people who create tools for people who author
SVG
... Adobe, for their SVG exports.
... I know fesch this isn't what you were expecting. You
forwarded me something along the ARIA lines
fesch: I like how you weave accessibility into the normal stuff. So, they don't have to read something separate. It comes with everything else
shepazu: That's the appraoch richardschwerdtfeger and I, and AmeliaBR and chaals have all talked about. This is how we'll get them
fesch: how will we bring up data visualizations without being very verbose?
shepazu: I expect visualizations
will be a large section of this
... we don't know all the details yet. I'll introduce the
principles of visualization, much like ARIA. Mention principles
but don't go into everything
... include the individual datum so that it can be logically
consumed. Not just for screen readers, but for anything
... as we're moving to voice enabled systems, Siri, search
tools. Lots of tools want to consume data and then present it
to the use
... we need data in a way to present to users. Voice systems,
that's the angle I'm going to come at it there. Here's why,
here's how you do it, we're going to do another document
... I'll already have explained ARIA. So that you can label
things "this is the legend", "this is the x axis", so they know
you can expose this to a machine. Makes sense?
... I don't think there's much more to say until you read
it
... by then, I may have added a bunch more stuff
... I'm not available next week, I'll be in Berlin. I'll be in
the week after
... can we talk about it two weeks in?
AmeliaBR: we will have our questions for you on the 25th
shepazu: Pull requests are welcome! Send emails, whatever. Though I am interested in discussing over voice
fesch: anyone have anything else?
richardschwerdtfeger: I will not be available next week
shepazu: why don't we not have a meeting next week?
fesch: I think we can do
that
... Anything else?
richardschwerdtfeger: AmeliaBR I've been tied up at work, but I've started those changes. Presentational aspects of elements. I am working on that
AmeliaBR: I'll be on the lookout for that and will update crosslinks on AAM
<richardschwerdtfeger> chair: Fred
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/nee to/need to/ Succeeded: s/ot have/to have/ Succeeded: s/adjsut/adjust/ Succeeded: s/confidence/confidence in Amelia/ Found Scribe: Brian Inferring ScribeNick: Brian Present: AmeliaBR fesch Brian shepazu Regrets: Leonie_Watson Found Date: 11 May 2016 Guessing minutes URL: http://www.w3.org/2016/05/11-svg-a11y-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]