Independent User Interface Task Force Teleconference -- 01 Apr 2015

<trackbot> Date: 01 April 2015

preview agenda with items from two minutes

<Ryladog> scribe: Ryladog

<scribe> Meeting: IndieUI Working Group Teleconference

<scribe> Chair: Janina

Future of the IndieUI WG & TF: WBS Followup -- Janina

preview agenda with items from two minutes

<kurosawa> mute me

JW: IMS Global is interested in User Context doc

JS: Is now the co-editor of the Context Spec

Future of the IndieUI WG & TF: WBS Followup -- Janina

js: Thanks for completing the survey

<jcraig> survey results URL?

JS: No one wants up to drop the work. Majority wants to work with Web Apps and CSS. PF is going to be called APA

<andy> https://www.w3.org/2002/09/wbs/54997/201503_planning/results

JS: Accessible Platform Architectures = APA
... There was no opposition to the new name

JW: My pariority is to see the work carries forward as effectively as possible - with accessibility SME overseeing and working with those groups with clear expectations and deliverable
... We need more commitment at the outset if things move to other groups

JC: Whicha spects?

JW: The same issues. Who is going to implement and how. And then who. Thos e in A11Y have the expertise understand the work.
... Who need to be involved and how to make a process work - and find the W3C framework that will best acheive that

JC: One word of warning. It is going o be more and more difficult to get implementers involved in speccing vaporware
... If we develop a bunch of web API prior to nay platform support for them, it sideline the practically. We need to fight against spec bload
... No technology creep

<Zakim> MichaelC, you wanted to say joint TF model should address that, and PF can focus on requirements documentation

JC: Aspects could be covered without requiring the....?

JS: Others?

MC: I think the ides of joing task forces suggested on the survey - that should address James concern.
... APA is focusing on requirement documentation and rely on the spec group to implement that - it will work

JC: My concern is that most of the big groups have trouble editing them selves. ARIA is starting to get bloat in 1.1.
... It is a concern to me is that we try to focus on too much and we dont ever ship a version 1 becasue it never completes enough

AH: I support that. I wasnt able to complete the survey.
... I am not sure we need to include the GPII - but I am for the Schema.org
... Browsers are implementing Schema.org and work with that
... I think we have to get something workable on the ground

<Zakim> MichaelC, you wanted to talk about IP (after Andy) and to say self control is possible; but we still need a forum

MC: Respond to IP. I do not think there are not any memebrs of INdieUI who are not part of PF
... I d not think there are any issues with the User Context moving to the spec part of PF/APA

JC: Thre was a lot of reprtition from companies on the WAI charters
... We want to be inclusive - but we also want to be productive

JW: I think what MC sad is right. There is a spec side of PF - whether that she be seperated from the review side - may be woke d out
... I am not sure why ARIA should end up in by non accessibility groups - and it has to be addressed very carefully
... It could be an effective method moving forward. I want very strong relationship. Otherwise we will end up with the same people talking to eaach other and notthe implementors

JS: Events only - with WebApps -I have spoken with one o the chairs - that was very encouraging in them wanting ti take up the work with us in APA. And they want to kikstart
... I am highly encouraged by that

<MichaelC> WAPA: Web Accessibility Properties and Actions

JS: Another wrinkle - the prposal from MicroSoft that i an activity that would be about events and events management. What is your view about that proposal James?

<MichaelC> https://rawgit.com/cyns/wapa/master/wapa.html

JS: If you havnt looked at that please do
... We started working on events - folks got interested - the editing task force is looking at this use of ARIA in events. And I am unsure if this is jsut for accessibility or not

JC: It looks like it os specific to ARIA

JS: To work with AAPIs or mainstream?

JC: I would be against an "ARIA Request Event" for something unreleated to accessibility. This specific to ARIA request events.
... In contrast, IndieUI Events were planned to work with native markup but also custom ARIA widgets.
... I woudl want to limit this to ARIA

JS: We have to look at it and factor tht in
... We want a proposal that we could all live with

JW: Microsoft is proposing this work for WebApps
... That seems useful

;;

JS: User Context: it keeps getting shoved to the side. We have not reached out to CSS to see about their interested on working on User Context with us

JC: The work ha already been working done as media features are already being implemented in CSS4
... It is not that CSS is going to take up User Contect - itt is that they are taking up feature that were in IndieUI will eb implemented - some specific to seciryt

JS: It seesm that there are a number of features that they were not interetsed in taking up

JC: Given how this has happend in the last couplde of years - I suggest that we do not include things that are already in CSS and we get the securoty model in - and the things that dont firt will come in a future vrsion
... Specific example: whether are not your font size is enlarged Is that good to have in media feature?
... Might be better for a v2
... Perferred caption BG color - which is well with in CSS

JS: Timeline I think is at odds with the urgency with what Jason and Andy said
... It appeasr that it will take CSS longer to get to it
... If we get somethings done - it might becaome more attractive to CSS

JW: It doesnt seem to me as ammenable to a relationship with APA.
... Folks have different priorities - it doesnt seem like it may fit with in a joint-task force. Mayb something looser

AH: User COntext exists as it is - and can be used all over the place - might be implemented in different technlologies in different places

JW: We could set out a range of usable user preferences and that feature is provided for in an API and how they all get covered overtime
... not necessarrily a normative document....if that is what you are thinking

AH: Implementations have two implementations
... That is worth for a less formal document

JC: the media features that are referencable are referenced from the current User Context draft

AH: I tthink that is fine. One groupf not implmenting one of our fetaires - we just need to go out and find someone who will get implemented

JS: You actually have to work with vendor to get implementations

JC: We dont want what happened in ARIA - mdragdrop was added just haphazardly at the end
... Because it was speced and finalized before was there any real work done - but it not effective. I do not want to waste resources if there is not a way for a user to turn them on

AH: I am not arguing for holding up. One example: smalled interfaces?

JC: I current spec id tied to JS and CSS APIs
... The IoT that upport web technologies

JS: Alot of them do support web technologies - it goes to a company website.

AH: A lot of these things are no necessary implementable on web devices

JS: We can develope reqirements and user cases and notes if we are not going to craete specs

AH: My point was that those devices do not have OS like othet things

JS: Ther is not time to get another heartbeat out
... Well take that up when Jason gets back

Schema.org Mappings (Continued) -- Rich & Andy

AH: I'd rather have Rich here for this....

<jcraig> JC: Still not sure what this discussion has to do with IndieUI. The IoT devices you're referring to (thermostats, etc) have custom APIs controlled by the manufacturer; your control of that through a website is entirely unrelated to these custom APIs. Where they may overlap is controlled by each manufacturer.

JS: Jason may be unable to spend of all that time as he is fixing up his new house

<andy> https://docs.google.com/spreadsheets/d/1pb92piOlud5sXQadXYnbmtp9LCut26gv8ku-qqZTwec/edit#gid=0

AH: The only chnage is we started to map in the security model - whether it is relvant to a particlar context oe not

JS: We are talking about a heartbeat. Can we make a best guess as to what will survive th edebate

JW: I think that is feasible

JC: User- is a variable not a media juery
... These are currently not thongs that can be used with a CSS propoerty. REmove the prefox user-
... Full keyboard access would be @media keyboard access - but you cnnot set that as a property
... if you remove all instances of

<MichaelC> scribe: MichaelC

JW: would like concrete proposals for how joint TFs would look

JS: will bring forward as soon as we have some clarity

JW: seems WebApps is pretty clear

<jcraig> s/You can use all the stuff after that/if you remove all instances of "user-" we can debate the rest. the user- prefix referred to a CSS property value (variable), not a media feature as written here. e.g. font-size: user-font-size;

User Context less so

<jcraig> The syntax is also TDB. Might be font-size: user-pref(font-size);

<jcraig> For example, the one listed here as user-no-MotionSimulation was proposed to CSS as "prefers-reduced-motion"; we've determined its rare that a user ever wants "no" motion; but there are certain types of motions (zooms, parallax) that should be reduced or changes (crossfade, flat pan, etc) in order to prevent vestibular issues.

<jcraig> "no sound hazard" doesn't seem to make sense as a warning. if there is a hazard, the user should have audio off or down on their device thereby preventing a webpage from being able to present them with a hazard...

<jcraig> but it could work as a media feature, e.g. @media (audio: none) { /* flash screen if either sound volume is down or if user is deaf */ }

Independent User Interface Task Force Teleconference

01 Apr 2015

Attendees

Contents

preview agenda with items from two minutes

Future of the IndieUI WG & TF: WBS Followup -- Janina

preview agenda with items from two minutes

Future of the IndieUI WG & TF: WBS Followup -- Janina

Schema.org Mappings (Continued) -- Rich & Andy

Summary of Action Items

Scribe.perl diagnostic output