W3C home > Mailing lists > Public > public-aria@w3.org > January 2018

Minutes for Thursday, 11 January 2018 WAI-ARIA Working Group

From: Joanmarie Diggs <jdiggs@igalia.com>
Date: Thu, 11 Jan 2018 14:10:55 -0500
To: ARIA Working Group <public-aria@w3.org>
Message-ID: <2a0a9a7f-81c7-725e-994d-2895c6efd75a@igalia.com>
Link: https://www.w3.org/2018/01/11-aria-minutes.html

Plain text follows:


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

   Accessible Rich Internet Applications Working Group Teleconference

11 Jan 2018


          Joanmarie_Diggs, jamesn, matt_king, janina, Stefan,
          MichaelC, Irfan



          jamesn, joanie


     * [2]Topics
         1. [3]CSUN
         2. [4]Static/text role proposal:
     * [5]Summary of Action Items
     * [6]Summary of Resolutions

   <joanie> agenda: this

   <joanie> agenda: be done

   <joanie> [7]https://github.com/w3c/aria/projects/2

      [7] https://github.com/w3c/aria/projects/2

   <jamesn> scribe: jamesn

   jd: the process is what we described at TPAC
   ... we have to actually draft it - get approved then goes into
   ED but won't really go in until we get the mappings etc.
   ... when time to get mappings might create an issue in core AAM

   mk: all the entries are issues - I have only occasionally used
   the notecard feature
   ... I think I can see .... ok ... ok. I think I can see here
   how to parse this information. I wish it was easier to tell
   when 1 card started and ended.
   ... will send feedback to github.
   ... helps me to be able to recognise the patterns. When I
   create them I know what they are but when someone else creates
   it then it is harder

   jd: in terms of doing the cards - I will probably do it one way
   and then hopefully we can all start doing these together and
   will figure out what works and doesn't

   mk: in order to edit/change cards etc the person needs commit
   access to the repos


   jd: was not on the agenda to the mailing list
   ... could we have a group meeting?
   ... MC shared some thoughts
   ... who is going

   mk: I am going. After hung up with glen gordon - talking about
   F2F - should have raise the CSUN possibility
   ... there are topics in that space I would like to get
   discussions going on
   ... if can get enough of the right people together

   jd: who are those people?

   mk: some of the windows people.... apple doesn't normally send
   people to csun
   ... chrome, mozilla, nvda VFO

   jd: James Teh not at CSUN this year
   ... Monday b4. Is that part of the conference?

   mk: M & Tues pre-conference
   ... opening keynote Tuesday evening

   <Irfan> *present Irfan_Ali

   bg: flying in on tuesday

   mk: already made flight arrangements?

   jd: probably not going to have people wanting to meet monday or

   mk: would be worth planning for 2019
   ... lessens the overall impact of adding F2F meetings to our

   jd: a key moz person will not travel to CSUN
   ... moz HQ looks like something we can raise with them
   ... looks like no ARIA WG specific meeting this year - but
   pursue actively for 2019

Static/text role proposal: [8]https://github.com/w3c/aria/projects/1

      [8] https://github.com/w3c/aria/projects/1

   jd: my reasoning was not to discuss the cards themselves
   ... but the new feature itself

   <joanie> [9]https://rawgit.com/w3c/aria/role-static/#static

      [9] https://rawgit.com/w3c/aria/role-static/#static

   jd: we deep dove this previously
   ... now with 1.2
   ... no one had any further changes to this content
   ... this cannot go into master/ED until the group agrees they
   are happy with it
   ... I am fine with it

   mk: I am still not fine

   <Stefan> +q

   mk: think it is a sledgehammer where might need a different
   ... I am not convinced of the use cases.
   ... it is a section that flattens an entire subtree
   ... has powers similar to role presentation
   ... the number of problems it might cause for the simple use
   cases we are trying to solve
   ... if we come up with solid examples which require this - and
   if there is no better way then ok
   ... this role turned out to be an engineering/coding
   convenience where you didn't need a new role
   ... I want to see the code for them first

   <joanie> scribe: joanie

   JN: I think there are a number of uses for this role.
   ... And with ARIA there are always other ways to code things.
   ... So we can make that argument for many existing roles.

   MK: I disagree.
   ... The only way you can make a button is role="button"

   <jamesn> Stefan: Matt spoke of examples. In the snippet

   <scribe> scribe: jamesn

   UNKNOWN_SPEAKER: there are multiple examples
   ... examples explaining characters. From the original
   discussion. special characters could certainly be one usage

   jd: I agree with Matt on the concerns
   ... the example that JC must have come up with. Example 15

   <joanie> Authors MAY provide a fallback role for user agents
   that do not support the static role. In the following example,
   img is provided as the fallback role. If the browser supports
   the static role, the screen reader would be expected to present
   "I love New York." Otherwise, the browser would expose the span
   element as an image, and the screen reader might instead say
   "I, love image, New York."

   I will copy/paste the text

   <joanie> <p>I <span role="static img"
   aria-label="love">♥︎</span> New York.</p>

   prices on this page need this -


   mk: multiple roles covered by this
   ... multiple roles covered by the aria spec
   ... been there since 1.0
   ... not new

   stefan: could be a valid pattern for 1.1 roles
   ... in practices interesting that browsers which support
   multiple roles support the new ones

   mk: ex 15 is least compelling to me
   ... a span that displays an image
   ... is not text
   ... should be announced as a single charcter which is a heart.

   stefan: a character which represents an image

   mk: if the image is a heart then should be announced as heart
   ... the use case is the one where you are trying to create an
   alternative experience for text which is being read aloud
   ... if know for a fact that text is read aloud and know that
   the presentation is not important
   ... stickers/emojis atc. the user requests them to be read as
   meanings not images

   <joanie> scribe: joanie

   JN: I pasted an example from the adobe page.



   JN: They read as $999 a month.
   ... If they put a text on it, it would read so much better.

   MK: Correct, but they could also add a screen reader decimal

   JN: And hide it offscreen?

   MK: You could do that.

   JN: Hiding offscreen is a cheesy hack.

   MK: Whether or not it is, it's become commonly done.
   ... Though there may be better ways.

   JN: The static role is that way.

   MK: You're just trying to insert a decimal point. We don't need
   an entire role which smashes a subtree to insert a decimal
   ... But I'm still more concerned about how this removes
   information and seems to be pointing others in that direction.
   ... It encourages that.
   ... This makes me nervous.
   ... Imagine there's a text book, and the teacher asks, "Class,
   how do you think the use of images in this text is relevant to
   the author's message?"

   <janina> Have to go, Sorry!

   MK: And whether you use a braille display or synthesized
   speech, you'll be surprised that there's even an image there.

   JN: How is that different from what we currently have?

   MK: They'll have to jump through many extra hoops.

   JN: When an icon font is used, there is already hidden text.

   Stefan: Icon fonts with aria-label is very common.

   BG: I haven't seen the example. Are you saying there's a span?

   <jamesn> <price class=" plan_cost pro">

   <jamesn> <span class="superscript">US$</span><span
   class="superscript cents">99</span><span class="per_month

   <jamesn> </price>

   MK: All these are a single span, but the way it's written, you
   could put an entire table in there and replace it with a single

   Stefan: That's already the case with ARIA 1.0.
   ... If you want only a portion read, you could use a container
   role and aria-label.

   MK: This could replace the body the way the spec is written.
   ... There is no other role or property which could hide

   BG: I had a client where aria-hidden was misapplied to body
   content and everything was gone.

   MK: But aria-hidden is pretty explicit and clear. That's not
   the case with static.
   ... I'm not happy with this without .... Part of me is thinking
   we're trying to provide an alternative, audio-specific

   <jamesn> MK: what we are trying to do is provide an alternative
   presentation for things

   <jamesn> MK: what happens with unicode characters on braille

   <scribe> scribe: jamesn

   MK: want to better understand the braille consequences
   ... biggest asks is that the screen reader can get to the
   original content without the static role... The original
   content needs to stay in the tree

   BG: guaranteed to me misued

   jd: static was a way to solve the name
   ... static content is not interactive

   mk: I don't remember reading anything about it being ignored if
   there are focusable elements

   jd: can't do a must here

   Authors SHOULD limit the use of the static role to content
   representing words or phrases. As a general rule, if the
   content would be deemed too long for use as a heading or label,
   authors SHOULD NOT use the static role.

   Authors SHOULD NOT use the static role on interactive elements
   such as widgets or links, or on the ancestors of such elements.
   If an element with a role of static is, or contains content
   that is, focusable or otherwise interactive, user agents MUST
   ignore the normal effect of the role and expose the element
   with implicit native semantics in order to ensure that the
   element is both understandable and operable.

   mk: that is what i was looking for

   bg: clear to me from the spec side

   jd: I had serious problems with it. I rewrote it to make sense
   to me
   ... as a screen reader developer I could live with it

   mk: for a screen reader user - would I be able to read with my
   braille display letter by letter or would it do the way screen
   readers do images.

   jd: should be like an image

   mk: can navigate the alt text but not image. Here you wouldn't
   hear it is an anything
   ... need a UA must related to how it is rendered in the a11y
   tree. The text says it but there is no must

   bg: remember talking about this last year with rich and joseph.
   remember them saying how it would act in browsers... saying it
   needs to be copyable as if it were regular text

   may impact how screen readers do this... due to difference in
   role types is why there are pauses

   mk: if it is flattened as part of plain text then the browsers
   need to provide a text node in the accessibility tree that
   contains the label
   ... there is a bit of a problem here - if example 15 for
   example... need to communicate that there is an image there

   jd: there is no image
   ... there is a unicode charatcer there

   mk: need to retain that information
   ... semantically the right way is role=img aria-label=heart
   ... the out loud reading presentation is to replace the image
   with the text string
   ... for some of these use cases - it is open for interpreation
   ... author used the unicode charatcer rather than typing out
   ... completely suppressing that content

   bg: completely suppressing that content
   ... one fo the problems on touch screens is that it breaks by
   role type

   wants it seamless

   mk: in the modern world with stickers and emojis etc.
   ... screen readers are in the 80's and worth a discussion
   amongst screen reader devs and users
   ... reading my kids texts - they are a PITA to read at times
   ... due to how kids write these days - where thoughts are a
   mixture of presentations
   ... screen readers are falling short of what they need to be
   ... don't want to fix a fundamental screen reader problem by
   hiding info which could be relevant to the user
   ... dont have consensus

   jd: dont have consensus
   ... what are the next steps

   mk: think we need to be thinking about the problem we are
   solving and whether we are solving 1 problem and creating 10
   ... don't want us to go down that path

   jd: is there a formal objection coming - if so that is probably
   the answer
   ... or could you make changes in order to make it work

   mk: not sure.

Summary of Action Items

Summary of Resolutions

   [End of minutes]
Received on Thursday, 11 January 2018 19:11:33 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 11 January 2018 19:11:34 UTC