Minutes for ARIA telecon on 9 December

Minutes from the ARIA teleconference on Monday 9 December are provided below as text, and are available as hypertext at:

http://www.w3.org/2013/12/09-pf-minutes.html


   W3C

                                                                                   - DRAFT -

                                                              Protocols and Formats Working Group Teleconference
                                                                                  09 Dec 2013

   See also: IRC log

Attendees

   Present
          janina, Matt_King, Rich_Schwerdtfeger, Cooper, Joseph_Scheuhammer, James_Craig

   Regrets
   Chair
          Rich

   Scribe
          jcraig, janina

Contents

     * Topics
         1. ARIA 1.0; any remaining comments?
         2. outstanding implementation issues
         3. Publication schedule and Timeline
         4. @hidden
     * Summary of Action Items
     _________________________________________________________________________________________________________________________________________________________________

   <trackbot> Date: 09 December 2013

   <richardschwerdtfeger> meeting: W3C WAI-PF ARIA Caucus

   <richardschwerdtfeger> http://lists.w3.org/Archives/Public/public-pfwg/2013Dec/0001.html

   <jcraig> scribe: jcraig

ARIA 1.0; any remaining comments?

   <clown> UAIG comments: https://www.w3.org/WAI/PF/Group/comments/list?document_version_id=23

   JS: accepted comments (will add notes pointing to 1.1)

   RS: one comment was "banner should be landmark" (in HTML?)

   JS: comments came in pretty late in the process

outstanding implementation issues

   RS: two features at risk: menu events and click handlers on elements with clickable roles

   No ETA for WebKit or IE

   MC: mark as at-risk in CR document; don't have to pull out until January.
   ... 17 Jan 2014 as deadline for implementation
   ... Publish PR on 28 Jan 2014

   RS: 508 refresh is coming soon, too

   MK: Could we move that req from normative to informative

   MC: We could do that, if we modify the at-risk statement
   ... Another section (text alternative) already lists change from normative to informative

   (2B may be changed to informative)

   Clown: tests pass (that one passes now)

   <janina> scribe: janina

   mc: Need to know by Thursday whether we can remove the "at risk" on name computation

   mk: If we add informative option to menu events, we need to do so this week---by Thursday

   clown: Will raise this on UAIG call

   mc: Joseph can add the note re ATK/AT-SPI changes
   ... We have three versions of what the note does ... We need to decide

   [discussion of whether to include a URI, and what that URI might point at]

   <jcraig> scribe: jcraig

   JC: could use a redirect?

   MC: Bad practice to change normative URI

   RS: Tell her "We'll start work on it."

   <Zakim> jcraig, you wanted to discuss the other at-risk feature: click events on clickable roles and to mention ISSUE-616 at-risk feature

   issue-616?

   <trackbot> issue-616 -- ISSUE: Review potentially at-risk statement "When the user triggers an element with a defined activation behavior in a manner other than
   clicking it, such as by pressing Enter, simulate a click on the element." -- closed

   <trackbot> https://www.w3.org/WAI/PF/Group/track/issues/616

   MC: could resolve in HTML

   Clown: What about SVG?

   RS: SVG 2 has tabindex; this could go there.
   ... Though this moves ARIA into the realm of affect mainstream user interface

   Clown: Cynthia wants this section put back in for ARIA 1.1

Publication schedule and Timeline

   MC: on schedule, assuming director approval
   ... lots of work to do: Jan 28 schedule is aggressive, but doable.

   JS: Need to make sure we're on the ball starting early January

   MC: We'd announce PR on publication day: hopeful that's Jan 17th

   RS: Rec a month later?

   MC: If we get AC feedback and support, yes. If we get feedback, will be required to address it.
   ... optimistically 5 Rec status weeks after PR
   ... lobby them to vote yes with no comments (best for us)
   ... if comments needed, encourage including concrete suggestions

@hidden

   <richardschwerdtfeger> http://lists.w3.org/Archives/Public/public-html-a11y/2013Nov/0050.html

   Implemented in browsers as: [hidden] { display: none; }

   <janina> scribe: janina

   <jcraig> coincides with hidden DOM property

   rs: Steve intro'd concerns
   ... I agree this is loosely coupled to ARIA-Hidden

   <jcraig> this is totally unrelated to aria-hidden

   jc: Reason this is implemented is that every framework has something about this

   <jcraig> frameworks implement this el.hide()

   jc: Just to toggle display property

   <jcraig> el.hidden = true

   <jcraig> <el hidden> content prop

   <jcraig> el.hidden DOM prop

   jc: Change one, the other updated accordingly

   <jcraig> [hidden] { display: none; }

   <jcraig> default style sheet

   rs: There was the discussion about how this relates to ARIA-Hidden

   jc: But that's not this bug

   <jcraig> http://lists.w3.org/Archives/Public/public-html-a11y/2013Nov/0050.html

   <jcraig> "concluded that the spec should say explicitly that hidden='' trumps all CSS."

   <jcraig> this is a non-issue for accessibility, as long as the UA has a default rule implemented via display:none.

   <Zakim> jcraig, you wanted to explain how/why @hidden was added

   <jcraig> <el hidden>

   <jcraig> el.hidden = false;

   <jcraig> <el>

   <jcraig> [hidden] selector no longer applies

   <richardschwerdtfeger> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18574

   <Zakim> MichaelC, you wanted to say you could set something to hidden with HTML, override the CSS to make it visible, but the AAPI mapping still suggests itÂŽs hidden,
   right?

   <jcraig> Mozilla tracker discussion here: https://bugzilla.mozilla.org/show_bug.cgi?id=945194

   mc: TF question potential conflict ARIA vs CSS

   <clown> el.getComptuedStyle() - what's the "display" property, if <el> (no hidden attribute)?

   <jcraig> ""

   mc: Remove hidden returns CSS to default value
   ... ONly issue is author overriding to make it nonhidden

   <clown> [hidden] {display:block;}

   <jcraig> so in author styles: [hidden] { display: block !important; }

   <jcraig> I'd call that an author error

   <jcraig> MC: and bizarre

   mc: Choosing to create an inaccessible situation --- author choice

   clown: how inaccessible?

   jc: Discussion now to map hidden weak to aria

   <jcraig> <el hidden> (weak mapping to aria-hidden)

   <richardschwerdtfeger> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18574

   jc: A separate discussion whether to map weak and/or strong

   <richardschwerdtfeger> While I sympathize with Tab's rationale in comment #8 (and had made the

   <richardschwerdtfeger> same argument myself in an earlier mailing list thread), I think there

   <richardschwerdtfeger> are two reasons to not do this. The first point was raised by Boris in

   <richardschwerdtfeger> comment #16: "Making things with @hidden "display: none !important" in

   <richardschwerdtfeger> the UA stylesheet would mean web [pages] cannot override the display at

   <richardschwerdtfeger> all, ever." Secondly, it's possible for authors to opt-in to such a

   <richardschwerdtfeger> behavior by adding this rule to one of their page stylesheets.

   mc: Further down Ted says "this was considered, but we shouldn't do that, imo"
   ... As I read, Ted does not support !important

   rs: So he supports overide?
   ... So one needs to look at css in addition?

   mc: That's our concern when we filed the bug

   rs: We don't have an implementation guide that addresses this and includes CSS considerations
   ... An html5 would have to consider the special case for hidden that can be overridden

   <clown> http://www.w3.org/WAI/PF/aria-implementation/#exclude_elements2

   <clown> "Elements, including their descendents, that have host language semantics specifying that the element is not displayed, such as CSS display:none or
   visibility:hidden or HTML 5 hidden attribute."

   clown: Above from UAIG 1.0

   rs: doesn't address marked hidden but overriden to be visible, which is being allowed by 19277 resolution

   mc: H5 wg saying "we don't want to enforce consistency"
   ... TF bug asked to mark this as "important"
   ... We're OK defining this as "author error"

   <clown> http://www.w3.org/html/wg/tests-cr-exit.html

   rs: but really not

   mc: If we don't address this in our docs, we have to live with it

   rs: We have to address this in an html5 implementation doc

   <jcraig> The resolution should potentially include:

   <jcraig> 1. Make it an author error/warning to override the CSS display of elements matching [hidden] in such a way that it "unhides" the content.

   <jcraig> 2. Make the @aria-hidden weak mapping to @hidden only apply to the rendered display outcome of the element with all CSS rules applied. (e.g. <el hidden
   style="display:block"> would not map to aria-hidden="true")

   [discussion of whether people like, or ever liked, ARIA-Hidden]

   jc: Think we need both to resolve the issue

   clown: really like the first

   rs: #1 would wcag under "robust"
   ... wcag 4.x
   ... any problem with #2

   <jcraig> s/for work/to catch my shuttle to work/

   rs: Don't think #1 is enforceable, but can be a WCAG error

   <richardschwerdtfeger> ACTION: Michael Take the following text to the WCAG WG as warning or violation under robust "Make it an author error/warning to override the
   CSS display of elements matching [hidden] in such a way that it "unhides" the content." [recorded in http://www.w3.org/2013/12/09-pf-minutes.html#action01]

   <trackbot> Created ACTION-1319 - Take the following text to the wcag wg as warning or violation under robust "make it an author error/warning to override the css
   display of elements matching [hidden] in such a way that it "unhides" the content." [on Michael Cooper - due 2013-12-16].

   <clown> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19277

   <clown> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19277#c21

   <richardschwerdtfeger> Resolution: James Craig to add comment to defect 19277 "Make the @aria-hidden weak mapping to @hidden only apply to the rendered display
   outcome of the element with all CSS rules applied. (e.g. <el hidden style="display:block"> would not map to aria-hidden="true")"

Summary of Action Items

   [NEW] ACTION: Michael Take the following text to the WCAG WG as warning or violation under robust "Make it an author error/warning to override the CSS display of
   elements matching [hidden] in such a way that it "unhides" the content." [recorded in http://www.w3.org/2013/12/09-pf-minutes.html#action01]

   [End of minutes]
     _________________________________________________________________________________________________________________________________________________________________

Scribes: jcraig, janina
Present: janina Matt_King Rich_Schwerdtfeger Cooper Joseph_Scheuhammer James_Craig
People with action items: michael


-- 

Janina Sajka, Phone: +1.443.300.2200
   sip:janina@asterisk.rednote.net
  Email: janina@rednote.net

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup: http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair, Protocols & Formats http://www.w3.org/wai/pf
 Indie UI   http://www.w3.org/WAI/IndieUI/

Received on Monday, 9 December 2013 16:38:56 UTC