See also: IRC log
<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
<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)
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.
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/anish/avneesh/ Succeeded: s/xxx/COO of DAISY Consortium, Chair of EPUB A11y TF/ Succeeded: s/cp:/cl:/ Succeeded: s/xxx/any object/ Succeeded: s/any object/by images, and we need it referenced by any object./ FAILED: s/1'7/17/ Succeeded: s/lw: looking at incubating in cg, you should start talking with browsers.../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./ Succeeded: s/Custome/Custom/ Succeeded: s/cusom/custom/ Found Scribe: fesch Inferring ScribeNick: fesch Found Scribe: JF Inferring ScribeNick: JF Found ScribeNick: tzviya Scribes: fesch, JF ScribeNicks: tzviya, fesch, JF Default Present: Janina, Avneesh, Tzviya, JF, LJWatson, fesch, Charles_LaPierre, MichielBijl Present: Janina Avneesh Tzviya JF LJWatson fesch Charles_LaPierre MichielBijl Found Date: 17 Aug 2016 Guessing minutes URL: http://www.w3.org/2016/08/17-apa-minutes.html People with action items:[End of scribe.perl diagnostic output]