<jasonjgw> 549 approach
<jasonjgw> zakim list agenda
<jasonjgw> zakim list agenda
<janina> trackbot, start meeting
<trackbot> Meeting: Accessible Platform Architectures Working Group Teleconference
<trackbot> Date: 28 August 2019
<Joshue108> 549 approach
<janina> scribe: scott
two documents up for review: XR user requiements and real-time communication accessibiity draft
XR: Josh added additions based on list feedback
Jason and Scott provided comments on XR, any others?
Judy: will have additional comments at a later point
no additional comments outside of tpics raised
josh: wokring through speciifc comments, confident going in good direction
fleshing out well - over next week will resond and reach out for clarificaiton if needed
Josh: need to add defintion of XR discusison
Janinea: is tehre anything inimmersive web? need to be careful about straying form definition
janina: e.g. we may take a wider perspective ofr definition because...
josh: good to ahve broad definition but potentially compare with what we're talking about and what others talk about with XR
judy: suggest simple definiion: XR = VR, AR and MR
jason: note that had started discussion on central emeents, noted that XR device API specs doesn't atempt to define the technologies so much as to specif what kind of hardware and assumptions
for our purposes, user needs and how it works in applicaitons, accessibility - want to say more to describe hardware constriants
contemplate constraits outside their hardware assumptions
<Joshue108> https://immersive-web.github.io/webxr/
janina: speciicaiotn of API out of imersive web?
Jason: yes
josh: we are curently aout AR and VR, not such MR as that is more AR. Smpler the better
<Zakim> Judy, you wanted to provide info on the workshop I mentioned when there's next an opportunity in the agenda
josh: do you think you can
tighten introductory definitions
... doesn't have to change that much
jason: there's a paper that describes different forms of reality, will rpovide refernce
<Joshue108> SH: +1 to Josh that not a lot needs to change, but there are some structural definitions.
<jasonjgw> Scott: suggests defining XR first, then introduce/explain virtual reality and augmented reality.
<Joshue108> Define XR first and explain how it includes VR and AR.
good strcuture woudl be to look at funcitonal perofrmance statemetns, set in siilar terms in EU and US policy
<Joshue108> This relates to EN 301 549 http://mandate376.standards.eu/standard
idea: cove rprinciple function, undersntad interplay of human interaction and describing what needs/requriemetns are
josh: interesitng idea. Will this document be something that people ahve to comform to?
judy: no
josh: or are they informative requirements for people to refer to. determines functional accessibility requirements kind of things, purpose important
requriements or advice?
judy: used accesibiltiy user requirements theory to inform devleopment of specs/guidelines, never used user requirmeents and conformance
Should be deliberate not to raise that concern: purpose to inform devleopment, not requirements
jason: even though referred to policy sources, not implying normative element
just saying human capabity is captured in those states are useful organising principle in purpose of structring informative description
comments had no intenton fo normative implicaitons
jjosh: potentialy structuring them in that way has normative implications
we have to e careful if there's hint of requriement-speak about it, moves out of territory and may be interpreted as normative
also asked quesitona bout labelling of number requirmeents: may infer that this is something that people ahve to do which is not wanted
<Joshue108> http://mandate376.standards.eu/standard
<Joshue108> https://www.w3.org/WAI/APA/wiki/Xaur_draft
Need to format this in a way that's suitable for user requirements
need to stay away form normative does XAUR do that? did MAUR do that?
judy: with MAUR, very clear at time with two specs at the time was clear this was not a normative spec
josh: how did you make that happen
janina: had hTML5 elements; video and audio.
these were user requirements, nt user agent requirements
when that became clear, things were smooth. talked aobut what users needed form media and know it works for a long time
- Judy leave smeeting
jason: user requirements and user needs: funcitonal performer statemetns not easily misunderstood if document states clearly documetn is not normative
josh: we've got partiuclary set of user needs, user with impariments, etc partiuclar requriements in user requiemnts
we have broad user needs: user x wants to do y
then to what degree of explicitness do we need to define user need
jason: goes to one of my concerns on functional performance
scenarios for specific applications
should it be provided i specificaiton or library or, devleopment envinronment
doesn't tell me if i were writing an XR applicaiton that doen'st fit one of the examples, but uses XR and I want to be generically accessible, having exmaples doens't tell me what i need ot know
woudl rather have a sysetmatic hearing, speech, funcitnal support requirements
wht kinds of things would I need ot be thinking about?
give me a conception fo what I'd need to do for accessibe design
janina: need to give some exmaples and ideas
in MAUR: a) that's what we did
b) it was strategic way to do it
we found ourselves in situation where some of basic undrstanding
had to defend some bsic concepts from HTML groups
when laying out MAUR work in 2009, HTML felt the solutions were done were solved and had to say there's more
that's why we took approach that this is an issue. MAUR dos have suggesitons on how things might work
was useful to illustrate those things
second screen came about, adjust
otherwise reinvent wheel: need to give ideas on how things
goal: suport normative devleopment
jason: process-wise, is looking at MAUR helpful XAUR
josh: do admire MAUR
<Zakim> Joshue, you wanted to say then XAUR should not have extensive how to guideance and should focus on general user needs in XR.
generla repsonse: user case from MAUR striaghtforware as there are two elements We've got a braod chruch with XR
janina: agreed
josh: should this document should be relativley short, clear overview of various user needs, disability x can do this
place for people can start to think about that
won't necessary have detialed how ot do that, but oculd potentially link into other doucmetns that have the how-to
how-to should be in WCAG, Silver, FAST
call otu generic requirements
generally work for screen reader, generally work for keyboard, etc
building on top: good practice
preference: keep straight forward and simple
<sctot_h> janina: one thing we don't know is political environment
<Joshue108> JS: Short is good for a FPWD
<Joshue108> SH: +1 to Josh
<Joshue108> I'm speaking to people who are really happy that we are looking at this space.
<Joshue108> I'm speaking to a Phd student looking at XR and who was impressed by the XAUR draft
<Joshue108> Found it simple to understand
<Joshue108> And have shown it to others..
<Joshue108> As the conversation goes on, there is something to be said for simplicity
<Joshue108> a top level doc that gives people an in, and references Silver and other normative standards would be good.
<Joshue108> I hear things from people working in this space.
josh: keeping it simple with broad user needs, purpose is to say
'peple want to use VR and AR. here are the things they watn to do. educaiton, health'
list those of nice user needs - symics, navigaiton, interaciton
techncial challenges: eg webGL
little worried about overdoing it
FAST does this, WCAG does this, Silver will need to do that -
jason: still issue with no functional requirements.
concerned that if someone approached in next six months to build VR or AR applicaiton
what are all the accessiiblity needs we need to be satisfied with?
user stories, user scenairos would help...
scribe: but not going to tell them whatthey need ot know form a design perspetive
by the time we get constraints and timelines of otehr developemtns, where will people turn to if not this?
janina: answre: will turn to this document as towhat it shoudl contain and will offer their ideas
public draft
<Joshue108> SH: I think we are in agreement
josh: you're right, lets get it out and then brining in guidance
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/differetn/different/ Succeeded: s/theoryt o/theory to/ Succeeded: s/requiremens/requirements/ Succeeded: s/elemnt/element/ Succeeded: s/descriptoin/description/ Succeeded: s/implicaitons/implications/ Succeeded: s/normativ,e/normative/ Succeeded: s/anneeds/needs/ Succeeded: s/nuser/user/ Succeeded: s/funcitnal/functional/ Succeeded: s/speific/specific/ Succeeded: s/i/in/ Succeeded: s/librayr, devleopmetn/library or, devleopment/ Succeeded: s/htings/things/ Succeeded: s/thining/thinking/ Succeeded: s/specch/speech/ Succeeded: s/htere/there/ Succeeded: s/fel tsoltuiosn wre odne once cations/felt the solutions were done/ Succeeded: s/useufl/useful/ Succeeded: s/htings/things/ Succeeded: s/shoudl/should/ Succeeded: s/WCAg/WCAG/ Succeeded: s/environemtn/environment/ Succeeded: s/striaghtofrware/straight forward/ Succeeded: s/ot/to/ Succeeded: s/iwllneed to dothat/will need to do that/ Succeeded: s/funcitonal/functional/ Succeeded: s/approache din/approached in/ Succeeded: s/eill ntinh in yhsy vonbrtsiyon// Default Present: SteveNoble, Joshue, scott_h Present: SteveNoble Joshue scott_h jasonjgw Joshue108 No ScribeNick specified. Guessing ScribeNick: scott_h Found Scribe: scott Found Date: 28 Aug 2019 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]