<jaeunku_jemma> Jaeun Ku(Jemma) at University of Illinois
<jaeunku_jemma> scribe: Jemma
<jaeunku_jemma> aaaron:
<jaeunku_jemma> aaron: annotation became important aspect for google doc. we would like to describe doc semantically and annotation will be useful - ie. comments
<jaeunku_jemma> aaron: mealny at microsoft suggested to come up with use cases.
<jaeunku_jemma> aaron: high level question - ARIA role vs annotation vs styling
<jaeunku_jemma> aaron:To me, annotation is in-page link to add info - relationship to main content
<jaeunku_jemma> mattking:how comment will look like?
<jaeunku_jemma> aaron: it is like comment in ms doc
<bigbluehat> https://www.w3.org/TR/dpub-annotation-uc/
<bigbluehat> the model https://www.w3.org/TR/annotation-model/
<jaeunku_jemma> bigbluehat: Digital publishing did most of work in regard to online publishing but missing thing is the ties into dom and accessiblity tree.
<david-macdonald> http://spec-ops.github.io/html-note/index.html
<joanie> https://lists.w3.org/Archives/Public/public-aria/2018Oct/0016.html
<jaeunku_jemma> aaron: [he is reading] different types of use cases.
<david-macdonald> http://spec-ops.github.io/html-note/index.html
<jaeunku_jemma> melanierichards: we have a functionality to show another author popped up.
<jaeunku_jemma> is this about insertion point or ?
<jaeunku_jemma> stefan/mattking: description for the change (suggestion, proposal..) will be covered by annotation?
<joanie> https://lists.w3.org/Archives/Public/public-aria/2018Oct/0016.html
<jaeunku_jemma> aaron: https://lists.w3.org/Archives/Public/public-aria/2018Oct/0016.html
<jaeunku_jemma> aaron: would like to suggest to remove "annotation-type"
<jaeunku_jemma> mking: I was thinking that AT can have numerate version info
<jaeunku_jemma> including braile.
<jaeunku_jemma> that kind of functionality would not be possible.
<jaeunku_jemma> aaron: we can add token for each change.
<bigbluehat> https://www.w3.org/TR/annotation-model/#motivation-and-purpose
<jaeunku_jemma> joanie: that is a good point. we can hash out later
<jaeunku_jemma> young: we did not do annotation model/type intentionally in digital publishing group.
<jaeunku_jemma> young: current work from digital publishing group would help this proposal a lot.
<jaeunku_jemma> aaron:breakpoint tends to be associated text and it can be multiple although it looks like one. based on screen reader use case, it can be treated as annotation
<jaeunku_jemma> melanierichards:Regading ui platform, it currently provides rich experience..text arrangement has meta data(ex: attribute type id)..main point is
<jaeunku_jemma> self referencing annotation vs comments markup with different property has different model
<Zakim> joanie, you wanted to ask for UIA API docs so other APIs could potentially model their to-be-added solution on UIA's
<melanierichards> https://docs.microsoft.com/en-us/windows/desktop/winauto/uiauto-implementingannotation
<melanierichards> https://docs.microsoft.com/en-us/windows/desktop/winauto/uiauto-annotation-type-identifiers
<jaeunku_jemma> bigbluehat: explained how web annotation model works - it marks annotation(ie. span, div) and put in one place(ie. json file)
<bigbluehat> http://annotator.apache.org/ is the implementation of Web Annotation mentioned earlier
<jaeunku_jemma> aaron: discussion of "italisized text" case with web annotation model detail
<jaeunku_jemma> mattking: target of annotation sometimes need what semantic that is, such as comment so target of annotation may not be enough
<bigbluehat> https://www.w3.org/TR/annotation-model/#h-introduction -- this model might be helpful
<jaeunku_jemma> mattking: is the annotation the same concept when Ben said and Aron said?
<jaeunku_jemma> melanie: annotated text is annotation to me
<jaeunku_jemma> annotation itself has meta data
<jaeunku_jemma> mattking: it would be good to involve AT developers to mark up
<jaeunku_jemma> +1
<jaeunku_jemma> david-macdonald: what is the current status of web annotation model?
<jaeunku_jemma> bigbluehat: it was first used for the cultural heritage image such as the Monaisa painting to explaining the small part of the image..so on.
<jaeunku_jemma> we were explored aria role, rdf, html dom, but it was not part of charter scope. there is another group(T..?) who work on annotation ux.
<joanie> ack
<jaeunku_jemma> bigbluehat:accessible annotation working group will be nice.
<Zakim> joanie, you wanted to say this is clearly going to need lots of input from and guidance written by the APG TF
<jaeunku_jemma> joanie: There may be the possibility to work under APA incubator group.
<jaeunku_jemma> regarding "accessible annotation working group "
<jaeunku_jemma> stevelee: you may want to work with Personalization workgroup about this accessible annotation topic.
<MichaelC> scribe: MichaelC
al: some annotations could be verbose, e.g., comment threads
would be nice to provide a summary to AT
maybe annotation could use aria-label
optionally
mck: might want that summary visible on screen, so use aria-describedby
<jaeunku_jemma> +1 for using aria-describedby
jn: we could document authoring patterns, either way could be valid
by: if I´m an AT user and know there is annotation I might want to go to
how much should the markup tell me about what I should go look at
e.g., if there are 1000 comments, how do I decide how many to read, find my way back, etc.
I want to figure out state transitions and signalling between the content and the ¨annotation sidebar¨
al: we can do stuff in either place, want to do what makes sense for the author
by: I want to know I´m in the main text or in secondary text
how do I know that
some annotation could seem just the same as the main text
jn: in some cases the annotation is as important as the base text
so need to know about them and be able to follow them
by: annotated alice is an example, you only buy books for the annotations
jn: we can address much of this with authoring practices one there are draft implementations
al: so we can explore existing markup solutions to this
<bigbluehat> "The Annotated" collection mentioned from WW Norton & Co http://books.wwnorton.com/books/book-template.aspx?ser=The+Annotated+Books
sl: don´t get too caught up in user experience
this is a verbosity use case, different users want different settings
what we make available to users allow them to set
<Zakim> MichaelC, you wanted to ask about a region role
mc: do we need an ¨annotation¨ region role?
by: think so
jn: possibly
can explore that
jf: annotations also can address cognitive and learning disability use cases
would like to avoid an overly narrow solution
not just AT exposure
also think in addition to verbosity, there is importance that should be able to attach
by: makes sense
knowing provenance of an annotation helps determine that
e.g., boss vs stranger
jf: comments can bubble to top
by: that´s a machine choice, not necessarily mine
al: maybe a summary rather than semantic weight helps better
dmd: +1 to new role for annotation
sl: -1 to role for annotation
content of annotation can be in many forms
there could be regions, asides, footnotes, etc.
so role could confuse unless we have compound roles
there should be association between annotation and content
which means there is a way to determine that you are in something that is an annotation of something else and you can jump back and forth
at the moment this seems to fill the use case, unless we discover others
mck: +1 to authoring practices
what are hopes for timeline and next steps?
I´m hearing both grand proposals and tactical proposals, unsure what we should do next
al: make things as difficult as possible of course :)
jd: think we can do much in existing ARIA; can explore other things as well
al: would like to explore the existing ARIA in detail to meet the use cases
explore a couple potential new things if needed
mck: any new features, is that ARIA 1.2 or later?
jn: For a single property, we could probably put in 1.2
good to file an issue about that so we can start exploring
jd: can go into editors´ draft sooner
if the full workflow doesn´t complete in time for 1.2 spec, still in editors´ draft for maturation
al: think we´re close
I want to explore if we want multiple annotation types
mck: what´s case against that?
al: path of least resistance, UIA supports single type
mp: different properties support different values
at the moment could have different types of anntations, but not multiple type on the same annotation
we could explore changing that
keeping in mind it makes it more complex, so consider consequence
could use ARIAproperties instead
by: Apache annotator is an example of the approach we´re exporing
it´s JS on DOM at moment
Open Annotation CG is a shadow group
inactive but can be used to ping people who´ve been working on it
re author understanding, want to define when it´s necessary for things to happen in UX
<Zakim> joanie, you wanted to ask if we could have prioritized token list
jd: we need to discuss use cases before deciding on multiple types
if we go that direction, there could be a prioritized token list
which allows to simplify some of it
al: seems to make sense
jf: use case is broader than AT
so architecting more broadly will be helpful
by: +1
would like to anticipate features rather than discover missing later
we have a list of annotation types, just need people to suggest what should be in it
but also suggest instead of typing annotations, use purpose and motivations
not all the use cases haven´t been elaborated yet
<bigbluehat> +1 to making this real with proposals
al: I will circulate a proposal
<bigbluehat> purpose and motivations are described here https://www.w3.org/TR/annotation-model/#motivation-and-purpose
<melanierichards> https://github.com/w3c/aria/issues/749
RESOLUTION: Aaron will add annotations proposal to w3c/aria github issue 749
<jaeunku_jemma> https://github.com/w3c/aria/issues/749
ss: aria-rowtype, we discussed
jn: we need your help to address in the APG
<joanie> Documents for this topic can be found here: https://lists.w3.org/Archives/Public/public-aria/2018Oct/0015.html
ss: on columnheader
in ARIA 1.0 grids every columnheader is potentially active
in 1.1 it´s a bit different but still true they can be focused and contain actions
mck: yes, @@
ss: gap re headers
mck: if one columnheader has actions, every cell in the row should be focusable
<jaeunku_jemma> https://www.w3.org/TR/wai-aria-practices/examples/grid/dataGrids.html
APG has example with 2 sortable columnheadders but the rest focuable
<jamesn> discussing https://lists.w3.org/Archives/Public/public-aria/2018Oct/att-0015/Properties.docx - section Columnheader: active, aria-fixed=”true/false” and aria-filtered=”(string)”
haven´t gotten quite to that level of detail though, it´s in the example
save that for the ARIA Textbook
ss: need properties to indicate column is fixed and won´t scroll
given there can be autoscroll during keyboard navigation
mck: rowindex could do that
ss: column
mck: there is an example in APG as well
both rowindex and colindex communicate that
ss: how?
not clear from verbosity
also, we have aria-sort but not a filter
if a cell has a sort it acts as a column header though it isn´t one
not sure of impementation
jn: we can explore that
ss: columns allow filtering by arbitrary string, common in business applications
<jaeunku_jemma> https://www.w3.org/TR/wai-aria-practices/examples/grid/dataGrids.html
mck: filtering and sorting should be a joint issue
jn: does seem there are missing things
but should work out what´s missing, and what should be addressed with author guidance
don´t want to add properties to spec until exploring practices for existing feature
for filter, I´ve always put them on descriptons of the table itself
hard to find when down in a column
ss: I´m looking at dynamic filter
jn: sometimes you get a pre-filtered view
discoverability has been a challenge
mck: AT should handle the discoverability
sn: yes, but in practice hasn´t been
<Zakim> joanie, you wanted to reiterate the need to also sort out what ATs should do in response
jd: ^
mck: sounds related to my aria-at project
dmd: have tested the aria labeling properties in AT, varying results
jn: there is a proposal to disallow author labeling of a region
mck: been wanting that also
jd: e.g., div
mck: things with presentation role
ss: example shows nested column headers
can I apply aria-level?
mck: AT should support colspan
ss: that comes out of HTML
but is it sufficient?
mck: unsure, but seems to work afaik
<MichielBijl> scribe: MichielBijl
joanie: recently revised charter template now has a fill in the blank format
What are the other charters doing?
We needed at least a 75% completed implementation for each platform
We also need that for at least one AT.
I thought that was a pretty high bar to get over
And it proved to be just that
scribe:
Lots of discussions
<joanie> https://rawgit.com/w3c/aria/charter/charter/index.html#success-criteria
What I’m going to do now is post a link:
<joanie> For the ARIA specifications, implementability and interoperability of every feature will be demonstrated by having at least two independent browser implementations of that feature. In addition, for the Accessibility API Mapping specification(s), each ARIA feature will be shown to have at least one implementation in each of: ATK/AT-SPI2, MSAA+IAccessible2, AXAPI, and UIAutomation.
Proposed solutions to SC issues
Worked with W3C and individual member organisations
<Zakim> Judy, you wanted to also clarify my role in the charter discussion
Judy: in terms of introduction
I was also directly involved with trying to solve some of the issues
Joanie: we appreciate your help
*joanie reads paragraph she just pasted*
This kind of holds us to an even higher bar
Now we have to have every single feature implemented
A 100%
The good news is that we don’t have 100% in a single UA.
We could have 75% in WebKit, 75% in Gecko, and 75% in Blink, but those might overlap and cause 100% implementation.
Same for AT.
mck: Something that strikes me about this high bar
On Windows there are two accessibility APIs
It strikes me as odd to have both of those to have to implement every single feature.
Joanie: it’s not a too high bar
It’s not implementabilty in Windows
It’s implementability in general
In the end the AAM is bascially gonna be “here’s aria-foo, how are you gonna implement it in *insert accessibility API*
RA: *asked a question I didn’t catch*
<joanie> platforms are included. If needed, an Accessibility API Mapping specification will be split into platform-specific specifications, e.g. one for ATK/AT-SPI2, one for MSAA+IAccessible2, one for AXAPI, and one for UIAutomation. This will allow each platform's specification to progress along the Rec track at the timeline that best suits them. For specifications which are not split apart in this fashion, no
<joanie> platform will be dropped out of the specification without prior consultation with that platform's owners.
<joanie> Every effort will be made to take member organizations' schedules into account and to ensure all platforms are included. If needed, an Accessibility API Mapping specification will be split into platform-specific specifications, e.g. one for ATK/AT-SPI2, one for MSAA+IAccessible2, one for AXAPI, and one for UIAutomation. This will allow each platform's specification to progress along the Rec track at the
<joanie> timeline that best suits them. For specifications which are not split apart in this fashion, no platform will be dropped out of the specification without prior consultation with that platform's owners.
joanie: what this says is “I can’t get the API to support aria-foo”
because it has a different release cycle or such
This won’t block ARIA
We can currently test platform agnostic ARIA implementations
And that means that if gnome release cycles screw everything up
it won’t block ARIA releases
RA: If this is the current charter
Would we pass today?
Joanie: we would be close, and otherwise I could get us there
The two ways to address this
Let everything progress on a separate time line
On the one hand we want complete implementations
We are doing this for end users
If we don’t have 100% across the board that impacts end users
All platforms and UA vendors say they’ll implement the spec
Perhaps not today, but we’ll get to it
For pure implementability, if someone says aria-foo isn’t implementable, I can submit a patch to proof it is
RA: Assuming you’re speaking of a usacase
in which UA already has support for a given feature
and, in the cases where there’s missing platform support
I will point you back to 20-30 minutes about annotations
about missing UA support
this current charter would then that UA needs support on the platform
that’s not something that we can require or mandate
joanie: we could split it out (we split AAM into four specs)
It’s not that hard
If there was just this one feature (aria-annotation)
If every last feature was implemented aside from one
Can we scrap just that one feature
plh: do you mean we remove it from the spec?
jamesn: it would just not be mapped
we have stuff in some of them that isn’t mapped on some platforms
mck: my question is directly related
high level question first
so you have the ARIA spec, say ARIA 1.1, and if it has dependencies on four other specs
normative dependencies
Can ARIA 1.1 become a REC if one of those other specs is like earlier in the process?
How do these normative dependencies work across specs?
You could remove something from the dependencies
But the first bullet says “each feature”
But it wouldn’t be each feature because you removed something
plh: first we do not have that today
ARIA does not depend on mappings
It’s the other way around
<joanie> Mea culpa
It’s what we call the nature of the dep
In the case of ATK, you must implement the mappings over there
If in the ARIA spec you say this specific role must be implemented as described in the mapping doc
We must make sure that it’s done that way
It’s about how specific you want to make that normative dep
mck: I’m glad there isn’t
plh: In terms of the ??
???
We’ll give them a week to respond
Your AC rep can still reply
Judy: I think that Matt’s question is good
I appreciate your assurance Phillipe
I was lookiung for the exact language
And would like to just make sure that it’s crystal clear and doesn’t leave any ambiguity, since specs have gotten blocked for unexpected interpretations of dependencies before
plh: There’re no a normtive depencies
mck: in the past I thought they were dependencies because you need those docs to implement it
If it can progress through the REC track that’s really cool with me
I’m glad to hear that
I had this impression in the past that that created the dependencies
plh: I don’t think a charter should say which spec depends on another
mck: I wasn’t sure if the current wording of the spec created this dependency
???
mck: that makes it pretty clear that’s how you expose it
joanie: the testing dependencies is where I got confused
I think this is doable
Going back to the aria-foo and aria-bar, if we pull that one aria-attribute out of your ATK, are you guys okay with that?
RA: I’m gonna use Philippe’s opportunity
I’ll get back to you
Judy: We’vge been having a fair amount of email discussions
About this meeting
We thought we had that before this meeting
Grey area, that additional week
With the extention
Have to sent this out to addition commenters
plh: if something comes up
Give them a week to say “Are you good with this or not?”
Not gonna send that in a week, gonna send that today.
We’ll go on a case by case basis at this point
Joanie: It’s not what end users need
But removing the frontrow ???
If we don’t want any failures
Yes, we prefer to have all the implementations
RA: There could be additional implementations
Then we’re on the receiving end in a completely different way
jamesn: the difference is that the spec couldn’t advance
joanie: you could have all this awesome additional stuff that’s only in your platform
But if the things from the spec aren’t implemented
I’m not sure how you’re on the receiving end
jamesn: if it’s one other it would be fine
If one of the mappings sits in CR for a bit is that okay?
three months past? six months past? I think that’s okay
joanie: as chair, and implementer, I can’t look at other stuff.
jamesn: the whole point of splitting them up is that they don’t have to progress at the same time
plh: If after six months a new implementation comes along that’s a lot better
That’s fine'
jamesn: essentially you’re providing us with the mappings that we4 put in the document
joanie: it could be that initially
The other thing: I’m very pro to updating the AAM
I think the AAM should be current
Not be out of date because we updated our API
MichaelC: I’m already thinking of ways to automate AAM production
Judy: Philippe knows how to do it
joanie: so you need that week to mull it over?
RA: Yes
joanie: if the AC reps are OK with are we okay with it?
If people have doubts I’d like to hear them,
RESOLUTION: Accept draft charter in 2018-10-26 form, send CfC to confirm during AC final check
<Jon_Gunderson> For rhe APG discussions in the afternoon will WebEx be available?
IanPouncey: CSS accessibility API mappings
As far as we got so far is that MC created a repo
That’s pretty much the last time something happened on it
I’ll drop a link to it
<IanPouncey> https://w3c.github.io/css-aam/
I’m not a 100% clear on what a CSS AAm would look like
but some things sound obvious
Like core AAM contains things on hiding content
joanie: that’s now in ARIA
IanPouncey: there are other things that are likely candidates for CSS AAM
Ordering content with various layout
Like flexbox/gridlayout
It’s worth specifying whether DOM order or layout order should take precedence in the a11y tree
There’re bound to be others
But an awful lot of CSS doesn’t have accessibility issues
This is a question I really don’t know the answer to: there’re plenty of things that don’t influence the a11y tree that perhaps should
Something like typographical styles
joanie: it’s exposed no?
melanierichards: the exposure isn’t exposed
IanPouncey: I would like to hear from joanie in particular her thoughts on this
We don’t yet have an editor yet
joanie: I can help be an editor
mck: I have some thoughts that need to be in there
There’re are some things that need to be specified someplace
We had a discussion in Toronto
With ???
Right now in the generic role one fo the things we’re talking about is the default styling like block and inline
A lot of people have pointed out that a lot of browsers will guess how a text node should be rendered
They’re different between browsers like Safari and Firefox
That’s one area of exploration
Is the way that visual spacing and placement affects the accessibility tree
joanie: I want to make sure we have the same interpretation of accessibility tree
IanPouncey: we’re talking about how things are exposed
Order as much as anything
joanie: the strong attribute is not
mck: essentially the thing what we use in the ARIA spec
Like a node in the tree
I was talking about whether two words are part of the same node
Is it one text node or two nodes
joanie: does it have two spans or divs or something?
mck: like <span>hello</span><span>world</span>
In VoiceOver these will be two nodes
In JAWS they’re announced as one
Not sure if it’s represented differently in the tree
IanPouncey: we’ve 12 minutes, so maybe we can focus on next steps
joanie: I can be an editor
just to make sure we’re on the same page
different people tell me what accessibility is that are not in this WG
given these HTML elements how are these exposed
for ARIA is the same things
How are those exposed on a platform?
Right now you mention text elements
If something is bold
Gecko will give it as “weight 600”
And webkit maybe gives us “bold”
No matter what the UA is, I get the exact same attributes
One thing you could map
is get a table
if there’s a CSS style bold
Something like ATK should expose that as bold
aaronlev: I linked to the table
joanie: they’re descriptive and they should be prescriptive
What I’d probably do is start with the table aaronlev linked to and do a sanity check
Find out what each browser is exposing
And if it’s the same thing and call up the AT vendors
Is this right or are you hacking around it?
Given this CSS, this is the canonical way it’s exposed
If that’s not what a UA is doing then we can file a bug
That would be a concrete way to start
IanPouncey: yeah that’s pretty good
Starting point is put together a list of things that are relevant to this
Font and styles, layout
joanie: if we want SRs to expose grid layouts as a grid
We might want to expose positional information
Maybe it’s just an ?? attribute
What do screen readers need to do?
But we can discuss that with AT/UA vendors
IanPouncey: the CSS AAM right now is a reference to other AAMs right now
joanie: SVG AAM is kinda doing now what HTML AAM is doing
Yeah you have this dependency chain
But I can use SVG without ARIA
Another thing would be a simple statement
I’m of the opinion that table shouldn’t be exposed
I have all this code in Orca that decides wether something is a table
IanPouncey: table heuristics have been around for a long time
I know there’s documentation but wether it’s canonical documentation I don’t know
aaronlev: we expose it as a table
We’ve been asked to
The screen reader can use our guess
joanie: WebKit now bases it spacing
aaronlev: We used to do that
joanie: if CSS layout table should work that way
???
aaronlev: yeah I’d like it to work that way but there may be different opinions
mck: ?? chops engineers off at the knees
joanie: Engineers of web apps?
mck: ???
to the extent we can remove ambiguity
<Zakim> aaronlev, you wanted to say here is our IA2 and ATK expose text attributes: https://wiki.linuxfoundation.org/accessibility/iaccessible2/textattributes
aaronlev: remind to remind me to look at this for AT2
We don’t expose every CSS attribute for font style
mck: so it’s color 0 = 0?
aaronlev: it’s up to the AT to understand that
When the AAT doesn’t see the value, it should assume it’s the value in the column
Over the years we’ve talked to the AT and they agreed
IanPouncey: should we write an AAM for this?
*laughter*
joanie: if we have to figure out what all the different platforms are gonna do…
aaronlev: yes that’s what we agreed upon
joanie: but that doesn’t mean expose everything
in terms of AAM language, HTML AAM will say something like ???
IanPouncey: CSS is developed by module
That provides a logical grouping to tackle this one thing at a time
joanie: an authoring practices, be it ARIA APG or a CSS APG
IanPouncey: As I said this at the start
What we need is
I’ll talk to Rossen
Who is a co-facilitator for the CSS WG.
joanie: you can sign me up as not full time editor
MichielBijl: you can sign me up as copy-editor type situation
<melanierichards> scribe: melanierichards
matt: we're approaching almost a
year since our first formal release of APG for ARIA Authoring
Practices 1.1, covers a small but vital portion of ARIA. The
vast majority of ARIA widget roles. Goal is to have all widgets
covered by release 3 in this December, possible exception
focusable [missed]
... we have 37/46 properties being used throughout current ARIA
examples. this is all covered by main section, the design
patterns. The big gap is it's one thing to show people how
things are used and prescribed how to used in pattern, but that
doesn't teach them how to use outside the context of the
pattern and use it generally
... we don't necessarily teach web devs how name from contents
or author works
... upcoming plans around aria-label, aria-labelledby,
etc
... the only role that has a section is role presentation,
don't have guidance on the other approx 86
... we've been doing a relase every 6 months. Going to do one
in December, June. End of next year we'll publish APG 1.2,
which goes with ARIA 1.2
... for a long time, our roadmap has been we will have all of
1.1 covered at that time
... at our current velocity, that looks unattainable unless we
get a whole lot of help
... I have a plan to get decent help (for ex contract work,
that's what we did to get regression testing into
examples)
... have some budget to generate content, but not sure if
that'll close the gap on its own
... we have another big project in our plan which the entire
industry has been clamoring for, a sort of "can i use" for
ARIA. we will structure based on pattern, roles in isolation
doesn't make sense
... if all the patterns cover all the roles, you essentially
have a Can I Use
... we will test specific browser + AT combinations and assess
how well they support that specific pattern
... this project I refer to by its repository name, aria-at
https://github.com/w3c/aria-at
matt: goal is not just to define
the patterns but how well they support it
... we don't have normative reqs on AT, so defining and
negotiating the methodology is probably one of the hardest
parts of the project
... from a practical standpoint this is what we all need
aaron: how often do you plan to retest stuff?
matt: once we have a methodology
in place and have proof-tested it across 10-12 patterns in all
the browser + AT combos, we'll build into this a way of
providing feedback loops within the infrastructure itself. so
we can update as updates some from screen reader updates
... part of this depends on how difficult it is to do the
assessments
<Zakim> yatil, you wanted to say MDN is trying to do some similar things like aria-at, might be a way to cooperate. Also there’s the accessibility support database infrastructure from a
<jemma> https://twitter.com/a11ylondon?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor
yatil: I've been at the MDN accessibility hackathon in London and they tried to do something similar, might be a way to cooperate. There's an accessibility support database in the W3C a few years ago, very dormant because people don't know about it. Can either use that or its learnings
matt: going to reach out to Shadi
[spelling?] about that tool
... the one thing I'm not sure about when it comes to there
being an authoritative reference for guidance when it comes to
roles, states, and properties...I know that MDN is well
regarded but it's not W3C.
<Zakim> jamesn, you wanted to ask whether the discussion about which combos we will look at has been had yet
jamesn: I don't recall us having a discussion about browser + AT combinations, we should understand that
CurtBellew: would be handy to know what's not supported now
<jemma> lauriat
Lauriat: it's been awhile since
we've caught up on this, I want to reiterate the support I have
for this. As you and I have chatted, in Google, my team has
done parallel effort on this. Implementing ARIA widgets and see
what works or doesn't. Want to see what we can contribute for
alternate ways of doing things or pointing out gaps
... have done testing as well, have started with most common
browser + AT combos, ones that have claimed to have done
well
... I have work to do to figure out how to contribute
... want to track updates so that we can link them to known
bugs
... from those bugs we can also cross-reference back to
aria-at
... need to have a full regression test once in awhile and
don't have a good answer for that
jamesn: are your examples public?
Lauriat: I am working on making
them public. We started in January and "finished" in April. On
an internal public repo but there's nothing inherently private.
Before I take a repo and make it public I have to go through
lawyers
... I can file bugs on Github
aaron: some ATs and browsers update automatically and others don't, something to think about for strategy
matt: this would have latest,
current status vs. different browser and AT versions
(history)
... we're also not going to be testing each release of browsers
and ATs
... will be a record of which one was tested
... you would have historical results perhaps for a specific
pattern, but when you look at the table of current statuses,
you might be able to open something in Github and find out the
history
jamesn: always useful to have that history
IanPouncey: can always track the point at which it starts working, supposing it never breaks
[general laughter]
aaron: people most often ask about JAWS a couple versions back
jamesn: we're not going to go back and do historical work
matt: if someone wants to do
that, that can be their own thing
... idea is to get industry up to a point where if you're using
recent browser and screen reader, you're going to get a robust
experience. Not the state of things today but we would like it
to be
... not sure if 2 year, 3 year goal
... can go way beyond that. can include mobile browsers (not
included in initial scope)
... might have to add AOM and other things that pop up over the
years
MichielBijl: object to not including mobile VoiceOver in initial scope
matt: I mean the very first go-around here, concept testing in a very small number of browser and screen reader combinations to test if it's feasible
MichielBijl: would really like to include touch screens in that because we've been terrible about supporting
matt: we can include touch
screens on a couple patterns
... ...it is possible to make a slider that works on mobile but
AT has to see plus and minus buttons
... point of APG is to show how we intend ARIA to work, and not
to provide polyfils
<Zakim> jamesn, you wanted to say is it not useful to report that
MichielBijl: we could always say "this pattern doesn't work with touch" to have that data point
matt: we've tested certain patterns with mobile, like dialog and menu button. have a couple bugs open. we do have a giant gap here. If anyone wants to join the task force to focus on mobile, please let us know!
aaronlev: I think we need to do
something about mobile. It takes so much longer to update the
experience for mobile users so the sooner we have data the
better
... can be up to a year and half from the fix to getting to the
user (due to OS updates)
matt: we need people. Our current group is already stretched to its limit
<jemma> we have abstract info about "Browser and Assistive Technology Support" in each APG example. https://www.w3.org/TR/wai-aria-practices/examples/grid/dataGrids.html
jamesn: we also have our new workflow where we require a pattern in APG for each new feature, and we still have the same number of people in APG, so backlog is growing
matt: if any companies are
willing to invest in this and oversee contract, contract work
went really really well for us, got a lot done
... if I could double my budget, that would be great. I'm happy
to provide project management aspect
... that's going to be a method I'll use more and more to max
our output
Lauriat: happy to help sponsor
mobile testing
... most of the work we do is to support apps, we have fewer
mobile apps. didn't bother testing our ARIA implementations in
mobile because we knew everything would be broken
... though we wanted to test mobile
<jemma> +q
jemma: potential place for that information...browser can add support info in each example
jamesn: [struggles getting people
to commit to get involved in contributing]
... how can we make that better?
Lauriat: part of it might be the format. the page inherently includes a whole lot of stuff: documentation, multiple examples on a page, etc. Maybe if the example opens its own new tab, clean namespace with docs around it, that makes it easier
<yatil> [Notes that we are working on our examples in EO, too.]
melanierichards: is there a human element where people don't feel that they are entitled to contribute? (imposter syndrome)
matt: there a some better starter points for new contributors (mobile testing, bugs, etc), developing a new pattern from scratch is not the best place for a new person to start
jamesn: [mentioned before matt that the first review can be rough, a lot of people jumping in to review]
IanPouncey: maybe that first review doesn't happen, it's a pair review / mentorship [paraphrasing]
jamesn: could consider for new people
<jemma> +q
matt: we want to create some UIs we know people can actually use, at this point we know it's spotty
Lauriat: first part is getting map of support, second part is filling it out
david-macdonald: contributions are just pull requests?
jamesn: we have branches with stuff that haven't been merged
david-macdonald: so file an issue and say you'd like to work on it?
jamesn: yes and someone can tell you go ahead or we already have something
MichielBijl: some kind of docs about directing new folks to the right place for help in contributing
matt: we have something like
this
... for a little while, was putting a lot of effort into
startup documentation. Ian contributed style guide. Docs on
getting linter set up, all that
... whatever you can do to help us improve that, would be
great
IanPouncey: we should have not
just "here's what you need to do" but also "here's what APG
will do for you if you contribute"
... happy to look this over
yatil: good idea would be marking issues as "good first issues"
matt: we have a link to "first
good issue" query on the docs
... I have a hard time figuring out what might be a good first
issue
... sometimes it seems straightforward to me and then when I'm
reviewing the PR, it seems harder than it looks. Sometimes it's
apparent.
yatil: APG is a document in the TR space and it looks like one, and I'm scared of TR space
jamesn: talk about moving out of
TR space, only problem is versioning
... don't want to put stuff in there that's not well
supported
MichaelC: we can do versioning wherever we want. open to the discussion of moving things
matt: with a lot of the ideas, it's a question of where it sits in the priority list. even something simple takes up time. I'm just trying to get version 3 out the door for December, so January is best time to have the convo
jamesn: can EO help?
yatil: happy to help how we can, we have a lot of stuff on our plate, but if we can have a shared doc, great
matt: this has been really helpful
jemma: any plan on how to create shared doc?
matt: we're just planning a meeting to get in touch in January (myself and Eric will coordinate)
yatil: want to align so we don't have separate examples
Stefan: we need a reference
signaling pattern for unobstrusive notifications needed
... we need some more patterns to signal to the user, so much
data fetching that has nothing to do with DOM building. Yes,
could re-use live regions or this and that, but there's no
patterns on how to signal business loading logic
... single control data loading, busy state is busy fetching
data, need examples for how to achieve this. aria-busy intended
for another purpose
... announcing results of search performed, "x results found"
etc. No established pattern to indicate this
... when you try to experiment with different browser and
screen readers combos with live regions, you don't always get
expected result
... need some patterns about "the UI has done/is doing
something" and "the UI is about to do something"
... any data-containing field needs to show it's busy fetching
data
... readonly or disabled not enough because you don't know
reason why
jamesn: these all seem like instances where the only way to do them is live regions. Wrong or right about that?
matt: we did make some mods to
aria-busy when we added feed role in ARIA 1.1
... one of those situations where the ATs haven't done anything
with it. If you just read the ARIA spec is not obvious what
you're supposed to do
... I think this is one of these places where the practices
task force really does need to step in a nd come up with
examples of how we think the problem would be solved, and then
suggest some reasonable expectations on the part of assistive
technologies
... would love some good use cases there, Stefan, thank you
jamesn: often when I use live
regions, I'm using it as a hack to throw messages to the
user
... what do people think about some kind of aria notification
mechanism to send messages to user
joanie: +1
matt: dispatch mechanism?
jamesn: yes
matt: you could potentially do it in javascript instead of having to have it in the DOM
Lauriat: in my previous
experience of using the crap out of live regions in G docs, we
learned a lot. Chrome Vox when it was an extension had a speech
API that we could just hit
... there are downsides. Such as the richness in formatting,
since you're getting a literal string that potentially has some
emphasis that gets lost
... loses intonation for emphasized words
... you get a lot from HTML
matt: this is where speech markup
would be really awesome
... it would be good if this ARIA notification thing could
support pronunciation
jamesn: would like Lauriat's expertise
Lauriat: sure thing
jamesn: will need sufficient warnings not to abuse this
Lauriat: doesn't solve the brittleness problem. anything else that's happening can stomp on speech. interruptions
Stefan: agree interruptions are a problem
aaronlev: booleans, "isInterruptable" etc
matt: screen reader support for live regions and this new thing...in both cases there's a lot screen readers coul do to make the end user experience a lot better. confounds me that SRs can't give history of latest live region utterances
JF: there is a task force that has been stood up to re-address SSML in education for pronunciation. Mark Hakkinen leading that. Caution this group not to re-boil the ocean, coordinate with this group
jamesn: resolve to open an issue
to look at this idea of ARIA notifications for messaging to the
user?
... Stefan, can you log it
Stefan: yes
<jemma> +1
aaronlev: I've seen this issue
with G docs, a lot things coming in and a lot of talking
... maybe companies w/ use case need to ask SRs to implement
something
<jamesn> logged https://github.com/w3c/aria/issues/832 for notifications issue
Stefan: we should have some sort of expectations documented
aaronlev: so we should include guidelines for how SRs should deal with the aria-busy state
matt: screen readers need us to come with very specific examples
joanie: can be brittle when the UA or the web dev sets something as busy but never unsets it
matt: some sighted people can read half the page when the other half is loading, and it frustrates me not to be able to do that
Stefan: complete list of valid
role="application" + aria-roledescription use cases
needed
... guidance says to reference the original role of the element
in the aria-roledescription before the more specific role
joanie: very long, takes up a lot of space in braille display
aaronlev: role attribute is semantic role, the other is a localized string
stefan: if both are spoken it's fine
[a couple people disagreed]
aaronlev: I think the way it works right now is good, space delimited name in the roledescription
(summarizing, Stefan had wanted both the role and aria-roledescription to be presented to the user by AT)
jamesn: aria-roledescription is poorly supported, what should do we do in the meantime?
james: we should file bugs against ATs
Stefan: recommended method how to
indicate custom control props using existing ARIA 1.1
needed
... is that possible to get in APG?
matt: if we had an open issue for something like the "filtered" example that would be good...I can't say until we start working on it how I would communicate filtered state
Stefan: in discussion with Rich, he said it was ok to use aria-describedby but can that be recommended by APG?
jamesn: have problems with using aria-describedby for things, not always spoken especially if verbosity turned down. that's why we have aria-errormessage. will have to work around these kinds of things in the future
matt: if you tes something and it works, you don't have to have that exact same technique in APG. The APG is never going to cover every possible UI, though I appreciate you're trying to do things as a standardized best practices
<JF> To get to Best Practice, you first need to start with "Practice"
matt: may need to build own best practices in order to unblock your engineering efforts, great if you contribute to APG when you're confident with it
<jemma> +1
<joanie> https://github.com/w3c/aria/issues/833
<CurtBellew> joanie : should we consider not allowing naming certain rules
<CurtBellew> I would argue that we've already had the issue
<CurtBellew> generic divs wiht names for instance
<CurtBellew> with the creation of generic roles
<CurtBellew> we might want to not let those have names as well
<CurtBellew> opened this issue - https://github.com/w3c/aria/issues/833
<CurtBellew> mck : i specifically asked for this for the generic
<CurtBellew> this thing has to be nameless. maintains interoperability for divs and spans
<Jemma> can someone explain what is the scope of "generic name"?
<CurtBellew> Adding this new value would for this to be part of hte accname
<Jemma> definition scope of "generic name"
<CurtBellew> joanie : if everyone can review and thumbs up/down
<CurtBellew> we need a specific list of elements that 'must not be named'
<CurtBellew> melanie : if someone adds a tabindex to a div, should we just say you can't do that
<CurtBellew> james : could be a region or a group?
<CurtBellew> mck : there are situations wher eyou might put a tabinidex on a div, like a dialog that contains a lot of content.
<CurtBellew> melanie : seems like it would be good to get author input
<CurtBellew> maybe we need some semantics if there's a tab stop here
<CurtBellew> jamesn : we do need semantics if there's a tab stop there
<CurtBellew> mck : there could be a situations where a span of text is something that you focus to and then has some other user popup but you don't want the content to be .... there are use cases ... it shouldn't have an accessible name
<CurtBellew> the focus should be on th econtent
<CurtBellew> joanie : generic is going to derive it's name form content?
<CurtBellew> mck: pretty sure it's not going to derive it's name from content. we need to find out if the content of hte text node is the label
<CurtBellew> jamesn : maybe we need to do some queries to find out
<CurtBellew> joanie : i will file the issue and ask Steve Faulkner to do some investigations
<CurtBellew> jamesn : move on to talk about generic role
<CurtBellew> carmacleod : you've been talking about my number one question. what attributes do we allow?
<CurtBellew> has been working on generic role today
<Jemma> https://github.com/w3c/aria/wiki/Plans-regarding-role-parity#generic-role
<CurtBellew> jamesn : role none doesn't happen if you put a global on it
<Jemma> https://carmacleod.github.io/playground/generic-role-tests.html
<CurtBellew> would we ever want any of the globals on the generic
<CurtBellew> mck : we might need to allow arir-invalid for instance
<CurtBellew> mck : the problem wiht putting a label on the generics causes other problems but among them is how does that get added to the tree
<CurtBellew> aaron : isn't it better ot have a label so the user has an idea of what's happening : worst case sceneroi
<CurtBellew> mck : maybe a browser coud do that even though the spec dosen't support that
<CurtBellew> one thing the spec doens't do is force you to do things that aren't support unless it says specifically to 'not'
<CurtBellew> aaron : if there's information there then I'd rather give it to the user and let them decide if it's usefull
<CurtBellew> mck : this might be one of those cases where it might be good that this doesn't work - it's bad code
<CurtBellew> mck : a div with a label - screen reader shouldn't read the label
<CurtBellew> otherwise the author might think it's good authoring
<CurtBellew> macdonald : testing it quickly and it doesn't seem to work on many statics
<CurtBellew> aaron : it's true. it shouldn't. when we get questions we can just say that it shouldn't work so it doesn't
<CurtBellew> jamesn : how do we solve the global attribute issue?
<CurtBellew> where we have things that are allowed but don't make sense
<CurtBellew> should we just say that they aren't allowed
<CurtBellew> currently as it's written if you put a role of none and an aria-label then it's as if the role of none is removed
<david-macdonald> http://davidmacd.com/blog/does-aria-label-override-static-text.html
<Zakim> MichielBijl, you wanted to ask about reversed role parities
<CurtBellew> mck : if something has support that is spotty how can author use it?
<CurtBellew> michiel : do we have any plans to go the other way - making HTML parity with what we can do in ARIA
<CurtBellew> might be good to at least open the discussion
<Jemma> +1 :-)
<CurtBellew> mck : the gap is a big one
<CurtBellew> caroline : the pull request is out of date at this point
<CurtBellew> it's not indicative of the current conversation
<CurtBellew> all the current information is in the issue and not in the pull request
<CurtBellew> mck : I put a bunch of stuff in the pull request
<CurtBellew> jamesn : mck comments opened a bunch of questions
<MichielBijl> To add: I’ll start a discussion with Scott O’Hara.
<CurtBellew> caroline : mck comments will be addressed
<CurtBellew> stay with the issue
<CurtBellew> jamesn : we will most likely not resolve this issue today. this should be a postponed to a future ARIA meeting
<CurtBellew> mck : i would like to walk away form this having answered an open question in the issue or the pr feedback
<CurtBellew> jamesn : nothing really waiting on you.
<CurtBellew> mck : maybe we need to get consensus on issue 833
<joanie> https://github.com/w3c/html-aam/issues/160
<joanie> Consider prohibiting author naming certain elements #160
<CurtBellew> mck : question on 160. how much of this an HTML issue?
<joanie> Related: https://github.com/w3c/html-aam/issues/158
<CurtBellew> is this any of this HTML AAM'
<CurtBellew> joanie : issue posted above
<CurtBellew> 'add generic case for name calculation'
<CurtBellew> if there is no aria role and no tabindex then it's not nameable
<david-macdonald> https://github.com/w3c/aria/issues/815
<CurtBellew> mck : both working groups should have input on this
<CurtBellew> joanie : if we expect users and authors to dig through docs to find elements that shouldn't be named
<CurtBellew> we should define that. these two issues don't seem to be duplicates
<CurtBellew> macdonald : is a heading a user interface element?
<CurtBellew> aaron : 'the nameless is the beginning of heaven and earth'
<CurtBellew> caroline : aria text separation
<Jemma> https://github.com/w3c/aria/issues/699
<CurtBellew> we need ways for the leading and trailing to specified separately
<CurtBellew> a token list would be a good way to do that
<CurtBellew> restricting it to two tokens?
<CurtBellew> feels similar to CSS
<CurtBellew> like before or after
<CurtBellew> mck : it's worth writing that way so it might be easier to get feedback
<CurtBellew> jamesn : we need something like this
<CurtBellew> jamesn : anything else anyone would like to discuss?
<CurtBellew> jamesn : next meetup? somewhere on the west coast of the US? next spring?
<CurtBellew> joanie : western canada?
<Jemma> scribe:CurtBellew
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/aron/aaron/ Succeeded: s/aron/aaron/g Succeeded: s/regarding to/in regard to/ Succeeded: s/to my recollection, w/ / Succeeded: s/benyoung/bigbluehat/ Succeeded: s/mealany/melanie/ Succeeded: s/this/ annotation ux/ Succeeded: s/cloe/close/ Succeeded: s/tpes/types/ Succeeded: s/openly/broadly/ Succeeded: s/@@/motivations/ Succeeded: s/seperate/separate/ Succeeded: s/features/mappings/ Succeeded: s/It’s/There’re/ Succeeded: s/not/no/ Succeeded: s/a// Succeeded: s/any ambiguity/any ambiguity, since specs have gotten blocked for unexpected interpretations of dependencies before/ Succeeded: s/initailly/initially/ Succeeded: s/productions/production/ Succeeded: s/topographical/typogrpahical/ Succeeded: s/typogrpahical/typographical/ Succeeded: s/qwill/will/ Succeeded: s/rtree/tree/ Succeeded: s/attribute/for font style/ Succeeded: s/CSS/CSS attribute/ Succeeded: s/a year and half/can be up to a year and half/ Succeeded: s/your/Lauriat's/ Succeeded: s/jamesn/Stefan/ Succeeded: s/globas/globals/ Succeeded: s/migh tneed/might need/ Succeeded: s/parties/parity/ Succeeded: s/reversed role parties/reversed role parities/ Present: MichaelC Stefan david-macdonald jaeunku_jemma irfan Luc_Audrain melanierichards Joanmarie_Diggs Lauriat stevelee CurtBellew_ mck Benjamin_Young mrobinson jamesn MichielBijl JF Judy IanPouncey CurtBellew Found Scribe: Jemma Found Scribe: MichaelC Inferring ScribeNick: MichaelC Found Scribe: MichielBijl Inferring ScribeNick: MichielBijl Found Scribe: melanierichards Inferring ScribeNick: melanierichards Found Scribe: CurtBellew Scribes: Jemma, MichaelC, MichielBijl, melanierichards, CurtBellew ScribeNicks: MichaelC, MichielBijl, melanierichards WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 26 Oct 2018 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]