Minutes for Thursday, 1 February 2018 WAI-ARIA Working Group

Link: https://www.w3.org/2018/02/01-aria-minutes.html

Plain text follows:

   [1]W3C

      [1] http://www.w3.org/

   Accessible Rich Internet Applications Working Group Teleconference

01 Feb 2018

Attendees

   Present
          Joanmarie_Diggs, MichaelC, janina, jamesn, Stefan,
          Irfan_Ali, jongund, clapierre, matt_king

   Regrets

   Chair
          Joanmarie_Diggs

   Scribe
          jongund

Contents

     * [2]Topics
         1. [3]Personalization CfCs:
            https://lists.w3.org/Archives/Public/public-aria-admin
            /2018Jan/0006.html
         2. [4]Using ATTAs for providing implementation feedback
            to browser developers
         3. [5]SVG-AAM roledescription issue:
            https://github.com/w3c/aria/issues/599
         4. [6]Using github reviews as part of workflow
         5. [7]HTML role parity
     * [8]Summary of Action Items
     * [9]Summary of Resolutions
     __________________________________________________________

   <joanie> agenda: this

   <joanie> agenda: be done

Personalization CfCs:
[10]https://lists.w3.org/Archives/Public/public-aria-admin/2018Jan/00
06.html

     [10]
https://lists.w3.org/Archives/Public/public-aria-admin/2018Jan/0006.html

   JD: Informative topic
   ... This is a link to the CFC list, any questions or commments?

Using ATTAs for providing implementation feedback to browser
developers

   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

SVG-AAM roledescription issue:
[11]https://github.com/w3c/aria/issues/599

     [11] https://github.com/w3c/aria/issues/599

   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

Using github reviews as part of workflow

   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> [12]https://github.com/w3c/aria-practices/issues/555

     [12] 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

HTML role parity

   <joanie> [13]https://github.com/w3c/aria/projects/3

     [13] https://github.com/w3c/aria/projects/3

   JD: The project is not fully completed, the initial project is
   still being created

   <joanie> [14]https://github.com/w3c/aria/issues/693

     [14] 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> [15]https://github.com/w3c/aria/issues/695

     [15] 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> [16]https://www.w3.org/TR/core-aam-1.1/

     [16] 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

Summary of Action Items

Summary of Resolutions

   [End of minutes]

Received on Thursday, 1 February 2018 19:09:32 UTC