<joanie> agenda: this
<joanie> agenda: be done
JD: Informative topic
... This is a link to the CFC list, any questions or
commments?
JG: What is the purpose of the ATTAs and test cases between specs
JD: Something that we want to
integrate into WPT
... Jon you were giving errors in the JSON files, so we need to
clean up code
... We need to use them for short term getting specs to
rec
... I have been talking to SF about using it for aam
... Long term about getting into WPT
JG: What about current test cases that fail
JD: You should triage to where is
the failure
... If I get a failure, I use the AInspector to see if it is a
"real" problem
... For me it was a problem with my ATTA
JG: So mainly this group is not interested in finding bugs
JD: The group currently doesn't have the have the people to do much of the testing and bug filing
JG: Ok, I understand
JD: Long term we will all be filing bugs
SS: I tried to summerize,
controls in HTML and ARIA
... You take some base roles, and you add custom roles....,
documenation for our blind users, if we can hook on some
text
... If we are able to extend description using role
description, I like it very much
... We have such controls extensions for aria input, like time
date...
JD: I don't think the situation
your taking about is related to the SVG issue
... The problem we are trying to fix..., the hack we put in the
ARIA spec
... If an element doesn't have implicent or explicit role, it
will not be exposed
... Something we did not think about, you can have something
like the METER element does not have an implicent role
... One of the work arounds is bad, author does role=group
role-description=power meter
This authoriing breaks accessibility because meters have values that cannot be communicated
JD: We want to keep wuhtors from doing this
SS: What about button role=group,
these are authoring errors
... Like you have something in SVG ....., pie charts...
JD: SVG could do that
BG: Described as social security,
the textbox is not exposed
... That's how the spec is written
SS: That may be the spec, and then I look at the mapping table
MK: It is inbetween what you and
bryan are saying
... Agree with Bryan, the screen should use as representation,
a textbox as a role descrption as foo
... The reason we have this other change, we insisted on an
implicint or explicit role, the screen reader needs to explain
the interaction
... It knows about a listbox role, but never says it
... The expectation is they only get one role, two would be
confusing
... Things might look like something else, but the interaction
is listbox, and the information on the page is about a pie, not
a listbox
SS: There is something like the original role, but it is different
MK: There is not consistent
implementation in screen readers
... There is concern that screen readers will read both
SS: It is OK when people rely on
the native role to be spoken by the screen reader
... What is the best practice, use the native role
MK: The expectation in the spec is leave it out
Bryan: If you add a role, it is
not going to go away
... It is a hack to get the screen readers to say something
else,... it is not going to change
SS: What I am hearing, it is safer to add the role...
MK: If you are going to do that,
don't use role description
... The APG needs a design patterns and examples
... There were things that were not included in ARIA 1.1 do do
these things, but to many descrptions makes something
unusable
... Ideally role descrption should be one word
SS: We should not bury this information in labels or other descriptions
MK: Its good for changing the role type, but not for help
SS: I don't want to use it for
help
... I think we need guidance on how to use
JD: Your concerns are not
directly related to the SVG spec, this is basically about how
to use role description
... People need to file issues on this authoring questions
SS: Your right you should not use role group, then people will ask what to add to SVG
JD: If something gives you a concern, make sure the issue is not being confused by the original issue, add a new issue
JD: New work flow
... If there is a change, people can make a branch and then
people can review the change
... Let's take the static text role
... Maybe MK should done a review
... Do we want to use the GitHub review feature?
MK: That's an appropriate use of
merge requests, seems reasonable
... I find them more difficult to follow, becasue of the
additional merge information on the page
MC: Sometimes there is a
different discussion, they should be moved to another
place
... Are you considering requiring the use of review
feature?
JD: Have people actually read it?
or are there crickets and joanie just merges
... Shane uses the review process and then I have shanes
comments
MK: Reviewing a pull looks
like...., one things I do in the APG, I check to make sure we
have specific reviews from people
... It is anothe way to use the issues, without using the pull
request
MC: There is a mandated review
for WPT pull requests
... If you want a specific person's review, it is good for
that
... If people want that, it will increase responsibilities,
engagement
... How many reviews are enough?
<mck> for example, a review issue in in APG:
<mck> https://github.com/w3c/aria-practices/issues/555
MC: Mandating review for merge,
might want to try, effectively ... JD or MC can't merge unless
there is a review that says this is good
... New features should have a feature
MK: Project is managing the process, people are assigned to specific issue
JD: We only have 13 minutes left
<joanie> https://github.com/w3c/aria/projects/3
JD: The project is not fully completed, the initial project is still being created
<joanie> https://github.com/w3c/aria/issues/693
JD: Before we decide what the generic roles, we know what we have parity for and we don't have parity for
<joanie> Verify we do NOT need new roles for these "not mapped" elements
<joanie> The following elements lack an ARIA role, but their mapping in the HTML AAM for all platforms is "not mapped."
<joanie> Assumption: If no platform has a need for them to be mapped, we presumably do not need a role for them. Confirmation needed.
JD: Dialog already has
dialog
... I don't know what all the web platform people want
<joanie> https://github.com/w3c/aria/issues/695
<joanie> [ROLE PARITY] Determine why these elements with ARIA roles have customized mappings for some platforms #695
JD: The aside element is mapped
to complementary
... The last 3 are the one's of more interest
... Please look at these 6 issues
... We need to know which need to be fixed, for example body is
mapped to document element
... In this case there are two many document roles in the
API
... MC what is the best way to get attention of the steak
holders
MC: For web components, Leonie
might be good, but she may come back with another contact
... I hope people do not get issue tracker happy
... The are 6 issues filled, we need there feedback on these
issues
JD: I don't wait until CR to hear their comments
MK: The ones you are proposing, I
think in the AOM space, James had an opinion
... Email James and tell him to comment
JD: Joanie will follow up with
these people, and I will e-mail the AOM folks, and that include
James (Craig)
... Other questions or comments
... I propose we do not do more work on role partity until we
get some feedback
MK: That makes sense to me
<joanie> https://www.w3.org/TR/core-aam-1.1/
JG: Is Bogden the main person to talk about UIAutomate mappings?
JD: Yes, he is not usually on
this call
... Bogdan and John Jansen sometimes don't get e-mails
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 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/MB:/BG:/g Succeeded: s/Bogden and Jensen/Bogdan and John Jansen/ Found embedded ScribeOptions: -final *** RESTARTING DUE TO EMBEDDED OPTIONS *** Present: Joanmarie_Diggs MichaelC janina jamesn Stefan Irfan_Ali jongund clapierre matt_king No ScribeNick specified. Guessing ScribeNick: jongund Inferring Scribes: jongund Found Date: 01 Feb 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]