W3C home > Mailing lists > Public > public-apa@w3.org > August 2016

Minutes from APA on 17 August

From: Janina Sajka <janina@rednote.net>
Date: Wed, 17 Aug 2016 13:08:17 -0400
To: W3C WAI Accessible Platform Architectures <public-apa@w3.org>
Message-ID: <20160817170817.GC1717@opera.rednote.net>
Minutes from the APA teleconference of 17 August are provided below as
text, and are available as hypertext at:

http://www.w3.org/2016/08/17-apa-minutes.html


   W3C

                                                                                   - DRAFT -

                                                        Accessible Platform Architectures Working Group Teleconference

17 Aug 2016

   See also: IRC log

Attendees

   Present
          Janina, Avneesh, Tzviya, JF, LJWatson, fesch, Charles_LaPierre, MichielBijl

   Regrets
   Chair
          Janina

   Scribe
          fesch, JF

Contents

     * Topics
         1. preview agenda with items from two minutes
         2. TPAC Planning -- Details Discovery; Note & NoteRef
         3. HTML Custom Elements Overview -- Leonie
     * Summary of Action Items
     * Summary of Resolutions
     _________________________________________________________________________________________________________________________________________________________________

preview agenda with items from two minutes

   <MichielBijl> Can someone pass me the webex link?

   <fesch> scribe: fesch

   janina: will identify folks

   js: we have a pair of topics - HTML and dPub
   ... introduced herselft

   lw: Leonie Watson , Web Platforms co-chair

   rsL Rich CTO a11y IBM

   fe: IBM co-lead SVG a11y tf

   jf: Deque, lots of W3C

   tz: DPub

   cl: Charles from Benetech, dPub TF

   avneesh: COO of DAISY Consortium, Chair of EPUB A11y TF

   js: main topics aria-details.... will Defer Shane's item
   ... work in HTML on custom elements

   ted: intuit a11y, joining Web Payments WG

TPAC Planning -- Details Discovery; Note & NoteRef

   <tzviya> https://github.com/w3c/html/issues/561

   js: we have a github tracker...

   tz: discussion on extended descriptions - result aria-details for all users not just AT users
   ... aria-details exist, not a good way to hide them... need to come up with some approach for all users
   ... creating attributes/properties that make it displayable (toggles) - give user option of display/hide

   lw: is the idea that someone has a icon (affordance) when closed, and a difference icon when open?
   ... are you asking for an visible icon (affordance) ?

   js: part of the problem with details/summaries is we need a way to know what is behind the presentation is an extended description
   ... and we can trigger this on ...

   rs: details element shows a button with a drop down icon
   ... they don't want a visible button as it disrupts the flow

   tz: we don't usually dictate display.... but a button saying summary can be disruptive
   ... if we could have something that triggers the extended description, that would be ideal

   <JF> "The aria-details attribute references a single element that provides more detailed information than would normally be provided by aria-describedby. Unlike
   aria-describedby, authors must ensure the content is not hidden and is included in a container that exposes the content to the user as it is expected that the
   assistive technology user navigate to the content to access it." -

   <JF> https://www.w3.org/TR/wai-aria-1.1/#aria-details

   js: there are reasons why we would want the presence of the details hidden

   avneesh: may need to visually exactly replicate a printed book

   lw: in the browser when the attribute is present, make the description available or show an affordance for the description
   ... HOW DOES THIS DIFFER FROM LONDESC?

   js: we didn't get that far, before the formal objection

   lw: issue invisibility of longdesc

   <clapierre> Longdesc only applies to images not other element
 like tables etc..

   rs: longdesc would actually take you to another page, details is in the same page
   ... that is a difference from longdesc

   lw: browsers don't want to change their UI

   jf: there is a disconnect between what Tziviya and avneesh .... and what is written

   rs: publishers don't want javaScript in the page...

   jf: is the content part of the page or fetched on demaind?

   ts: there could be links to external objects as well

   rs: can use iframes

   js: in the spec examples of both in the page and external

   cl: longdesc is only a reference by by images, and we need it referenced by any object.

   lw: I meant with regard to browsers whether it is visible or hidden

   ts: Avneesh said the default is descriptions are hidden, but in plain sight

   lw: so you would still see a little icon?

   ts: yes, but if it would be easy to turn off

   <JF> Presumably the "icon" would also be stylable using CSS?

   lw: I don't believe the default icon is styleable

   avneesh: we don't want to see anything there

   <LJWatson> <details> <summary proposedAttrib><img src="complex.png" alt="Complex picture"></summary> Detailed description here</details>

   tz: the default should be the icon is there

   <tzviya> https://www.w3.org/TR/wai-aria-1.1/#aria-details

   tz: you can see examples in ARIA 1.1
   ... examples 1`7 and 18

   s/1'7/17/

   lw: can someone put this discussion in github?

   js: would be nice to obsolete longdesc... but how do we approach web platforms?

   lw: we use the web platforms community group
   ... we are looking at a variant...

   rs: we could have a 3rd state to let it be platform defined.

   LW: This can be incubated within WPWG I think, rather than in the CG. I strongly suggest you tal to browser implementors to get feedback and test the water.

   js: there are two cases that need to be made, first case is other users that need to see descriptions, 2nd case is why it should be in a browser

   tz: reading system are based on browsers... thus need to start with browsers

   js: if webkit supports it it doesn't mean it is in FireFox, do we need it in the rendering agent or all the way through?

   lw: exit criteria - need 2 implementations in browsers not rendering agent

   <richschwer> I need to drop

   <JF> scribe: JF

   LJW: hoping to have Tzviya to update the github comments (as requested by Leonie)

HTML Custom Elements Overview -- Leonie

   LJW: Custom elements is part of web compnents (along with shadow dom)

   they are closely related

   Custom elements allows for the creation of new custom elements that currently do not exist

   closely related to Shadow DOM

   when you use somethnig like <audio> the browser creates the user interface

   that is all in the shadow DOM

   you don't actually see the pieces that are the audio player (buttons,etc. - that is all in the Shadow DOM

   Custom Components will be reflected in the Shadow DOM

   <Avneesh> a detail regarding reading systems, they use both the finished browser as well as rendering engines

   Work happening on that spec at both W3C and WHAT WG - some differences still

   active environment at this time

   <Avneesh> Readium has a chrome pluggin that makes it into a reading system, while readium also have a rendering engine used for reading systems in iOS / Android
   platforms

   clapierre: thought only Chrome supported custom elements, what is current status with other browsres?

   LWJ: Chrome is certainly further ahead, but other browsers are catching up. Not sure about Edge or IE however

   clapierre: Benetch is experimenting with Custom Elements in an eBook

   some issues have surfaced in that work

   LJW: interested in seeing that custom element as we continue to work on the details/summary thing - it may be useful for developing a proof of concept example
   ... aria will be critical when authors are creating these custom elements

   The question is now, how to make ARIA extensibel to those authors

   <tzviya> scribenick: tzviya

   JF: in W3C we worry about standardizing.
   ... Is the issue to make a checklist for creating accessibility for custom elements?

   LJW: Education will be a big issue
   ... A big issue with custom elements is that these specs are built to create new things
   ... These elements are often reusable and made to be packaged

   JS: The interest is not necessarily to claim conformance to a specific spec

   <LJWatson> https://github.com/domenic/html-as-custom-elements

   LJW: There is conformance to WCAG, etc
   ... Dominic documented all the conformance issues in HTML in one document, so that developers could refer to it in one place
   ... One use case is that forms are so difficult to style. People create custom elements just to make forms look good.

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     _________________________________________________________________________________________________________________________________________________________________

ScribeNicks: tzviya, fesch, JF
Present: Janina Avneesh Tzviya JF LJWatson fesch Charles_LaPierre MichielBijl


-- 

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, Accessible Platform Architectures	http://www.w3.org/wai/apa
Received on Wednesday, 17 August 2016 17:08:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:55:22 UTC