See also: IRC log
<trackbot> Date: 05 March 2014
<janina> Meeting: IndieUI Task Force Teleconference
<scribe> scribe: jasonjgw
<MichaelC> agenda order 1, 2, 3, 4, 13, 6, 12, 7, 8, 9, 10, 11, 12
Participants in the group introduce themselves to Hans (our new participant).
Hans is an accessibility consultant with The Paciello Group (TPG) and developer involved in WCAG testing and accessible content creation.
Daylight saving is introduced in the U.S. on Saturday, with other countries to follow (Australia is last to change).
Janina will attempt to ensure that time zone data are correct in the agenda, but participants are advised to check carefully.
The next scheduled meeting (19 March) conflicts with CSUN. Janina proposes to skip the 19 March date.
It is decided that the next meeting will be 2 April.
Europe will have joined the time shift by then.
No editor's updates since last time. A few new issues have been added (or rather, actions).
James: it isn't yet possible to implement valueChangeRequest on slider fully with a polyfill.
James proposes to re-introduce continuous events for the manipulation request: mouse/touch/scroll events for the various input devices.
He proposes that an element can have a ui trigger for a parent container. Example: a dialogue could listen for escape requests (e.g., escape key), and a close button for mouse/touch interaction. He proposes a uitrigger attribute (e.g., uitrigger="escape") on the cancel button, where the enclosing dialogue would be the event listener.
For the slider example, the continuous event would be dispatched as the user clicks and drags the slider thumb. The abstract (value change) event would be finalized when the continuous events end.
James proposes that the event listener for the value change request would receive the continuous events and the application event listener would reconcile the delta differences into it's model of the value change.
James acknowledges that the concept requires further elaboration for the details to be worked out.
The first polyfill that Hans might consider working on (scrollRequest) needn't require this mechanism.
This was covered in the item above.
Janina notes the need to advance our efforts in this area and to continue our work.
James notes that everything with a JavaScript interface can be automated and tested.
<jcraig> https://www.w3.org/WAI/IndieUI/track/products/2
<jcraig> action-57?
<trackbot> action-57 -- James Craig to Consider helpfocusrequest and mainfocusrequest in addition to toolbarfocusrequest and palettefocusrequest -- due 2013-06-27 -- OPEN
<trackbot> http://www.w3.org/WAI/IndieUI/track/actions/57
James suggests skipping action 57.
This is the IndieUI counterpart of landmark navigation, e.g., move focus to application tool bar. This has the drawback of potentially preventing the user from reaching the native tool bar.
He proposes shifting this item to IndieUI Events future release.
<jcraig> trackbot, associate action-57 with product-4
<trackbot> action-57 (Consider helpfocusrequest and mainfocusrequest in addition to toolbarfocusrequest and palettefocusrequest) associated with product-4.
James - issue 17 - bubble help request - move to IndieUI Events future release - we don't know how to achieve this on touch screen interfaces, where mouse hover would be used on desktop interfaces. In general, there is no consistent way to do this on all types of interface.
<jcraig> trackbot, associate issue-17 with product-4
<trackbot> issue-17 (Require an event notification and indicator that an element can respond to a bubble help request) associated with product-4.
James: we may wish to re-introduce the mark request, e.g., select series of messages and move them, or series of items and delete them, etc.
He suggests re-introducing potentially prior to the completion of 1.0, but only if time permits. If time does not permit, then associate it with a future release.
<jcraig> trackbot, associate action-25 with product-4
<trackbot> action-25 (Add markRequest with variant properties indicating "fromLast" (like Shift+click or select range from last mark) and "retainMarks" (like Mac Cmd+click or Win Ctrl+click meaning select in addition to)) associated with product-4.
Proposal: associate it with future release now and bring it back later if achievable.
James needs a better name for point-of-regard focus and blur. The name is long and isn't clear to those outside the assistive technology space.
James: we could use PORFocus.
Janina echos James' concern about its intelligibility to those not familiar with AT.
Janina suggests we provide a good glossary definition, irrespective of what we call these events.
James: focus implies that keyboard actions operate there; focal point could be the concept to describe what an eye tracker or screen reader is looking at.
<jcraig> jc suggested focalPoint and rich suggested operationalPoint
Rich and Janina discuss the currency of "point of regard", noting that the term is now used widely in accessibility.
There have been several recent posts on this topic. James acknowledges concerns about screen reader detection for the wrong reasons. There are scenarios in which it's desirable, James suggests, mostly confined to large Web applications.
Example: the use of live regions in large editing applications, effectively to control the output of the assistive technology. It's difficult to make the user's experience natural without detecting that a screen reader is running and what (in future versions) some of the user's preferences are.
James notes the risks of abuse of the screen reader detection capability, threatening users' privacy.
This cannot be used for example to collect data on numbers of screen reader users for purposes of justifying accessibility work.
Another example: performance concerns introduced by DOM manipulations required for accessibility. By enabling screen reader detection, the performance drop could be confined to cases where there is actually a screen reader in use.
<MichaelC> Why screen reader detection on the web is a bad thing
Rich: AT Compatible could be used here - screen reader detection as such isn't required.
James notes his follow-up to the blog post that initiated this discussion.
James notes that this feature would be subject to privacy controls and that many of the concerns raised in public about this issue can be addressed.
Michael: we should highlight this issue as requiring review in any public draft introducing such a feature.
James emphasizes that only large and complex Web applications should require screen reader detection.
He suggests only allowing this to be done under restrictive conditions.
It shouldn't be possible to do this from a frame.
Michael: existing security models can be brought into play here.
Michael suggests contacting relevant security groups.
<jcraig> action-80?
<trackbot> action-80 -- James Craig to Link notes about screenreader privacy concerns, and try to address in the screenreader section, not just the security section. Add normative statements that implementors MUST NOT implement high security interfaces like screen reader until the user security model is in place. -- due 2014-03-12 -- OPEN
<trackbot> http://www.w3.org/WAI/IndieUI/track/actions/80
<MichaelC> ACTION: cooper to ensure User Context public review version solicits input on the privacy concern of AT identification [recorded in http://www.w3.org/2014/03/05-indie-ui-minutes.html#action01]
<trackbot> Created ACTION-81 - Ensure user context public review version solicits input on the privacy concern of at identification [on Michael Cooper - due 2014-03-12].
<jcraig> ACTION: jcraig to link existing security restrictions for cross-domain [recorded in http://www.w3.org/2014/03/05-indie-ui-minutes.html#action02]
<trackbot> Created ACTION-82 - Link existing security restrictions for cross-domain [on James Craig - due 2014-03-12].
<jcraig> ACTION: jcraig to address whether certain additional restrictions (such as SSL) would be required for restricted prefs like screen reader [recorded in http://www.w3.org/2014/03/05-indie-ui-minutes.html#action03]
<trackbot> Created ACTION-83 - Address whether certain additional restrictions (such as ssl) would be required for restricted prefs like screen reader [on James Craig - due 2014-03-12].
Jason queries whether it might be possible to require the user to enable screen reader detection on the application side before confirming on the UA side, just to discourage unnecessary implementation by Web pages/applications.
<MichaelC> ACTION: cooper to open coordination review with Security group once we polish up our first proposal on AT identification [recorded in http://www.w3.org/2014/03/05-indie-ui-minutes.html#action04]
<trackbot> Created ACTION-84 - Open coordination review with security group once we polish up our first proposal on at identification [on Michael Cooper - due 2014-03-12].
James: there is a suggested
security restriction where the ua has to provide not just a
prompt, but a prompt with justification. The format of the
justification hasn't been decided.
... the goal is to make this more complicated than a
straightforward CSS media query or event listener registration
so that it will only be used when absolutely necessary.
Michael proposes to close the meeting and to discuss User Contexts more on 2 April.
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/accessibility consultant/accessibility consultant with The Paciello Group (TPG)/ Succeeded: s/the slider. T/the slider thumb. T/ Succeeded: s/ the continuous events./ the continuous events and the application event listener would reconcile the delta differences into it's model of the value change./ Succeeded: s/event listener registration/event listener registration so that it will only be used when absolutely necessary/ Found Scribe: jasonjgw Inferring ScribeNick: jasonjgw Default Present: janina, jasonjgw, Hans_Hillen, Michael_Coope, Michael_Cooper, jcraig, Rich_Schwerdtfeger, kurosawa Present: janina jasonjgw Hans_Hillen Michael_Coope Michael_Cooper jcraig Rich_Schwerdtfeger kurosawa Agenda: http://lists.w3.org/Archives/Public/public-indie-ui/2014Mar/0000.html Found Date: 05 Mar 2014 Guessing minutes URL: http://www.w3.org/2014/03/05-indie-ui-minutes.html People with action items: cooper jcraig WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]