W3C

- DRAFT -

Accessibility Guidelines Working Group Teleconference

01 Jun 2017

See also: IRC log

Attendees

Present
AWK, Davidmacdonald, jasonjgw, MichaelC, KimDirks, Katie_Haritos-Shea, JF, Kathy, MikeGower, chriscm, shadi
Regrets
Chair
AWK
Scribe
Detlev

Contents


I can do it

<AWK> Scribe: Detlev

orientation https://www.w3.org/2002/09/wbs/35422/MATF_orientation/results

<marcjohlic> “orientation” vs “display orientation” vs “screen orientation”

AWK: mixed bag 5 in favour, 6 seeing editorial issues, 1 sees problems

<marcjohlic> Is this applicable only at launch or throughout the app running

AWK: first question: is it device orientation, screen orientation?
... So it is display orientation (portrait/landscape)

Kathy: conforms: display orientation

AWK: so it is not about physical hardware in space

Jason: Prefers addition of "display orientation"
... Are there cases where users want to lock orientation via controls in web site
... ie on the app level not ua level
... this would need an exception

<davidmacdonald> comments https://github.com/w3c/wcag21/issues/193

<davidmacdonald> https://github.com/w3c/wcag21/issues/265

<davidmacdonald> https://github.com/w3c/wcag21/issues/235

Jason: So the requirement would be: Don't lock orientation unless requested by user

Alex: if a particulat piece of content does not affored rotation does that quality for an exception?

Marc: Might fall under the 'essential' exception

Alex: Talking about a type of device where rotation is not supported - and content is made more that device (like a projector)
... would that be an essential exception?

AWK: if that is part of your conformance claim (tailored to a particular environment) then yes? But you may not be able to prevent it?

Alex: May be prevented in things like virtual / augmented reality contexts
... Is that essential? If not we need an alternative exception

AWK: With a display with headset (goggles with phone) you don't want the display to flip 90 degrees when you tip your head, so it sounds like an essential aspect

DmD: another case: using an ipad in bed

goverm: A device may detect orientation OR an authir may restrict change of orientation - the author would not be dealing with that situation if the devcie restricts it
... It is only when the author tries t ooverride that

Alex: If the content is not locked to some orientation - will the exception apply? If not we have a problem

goverm: But in a device situation (headset on) this is specific - in another context it would be good if orientation can change

Alex: If content is only available to the VR environment the content is locked to one orientation - it would not go to a laptop

goverm: there is no signal from the OS to flip orientation so the SC would not be applicable

AWK: In another context where authors lock orientation on an ipad or phone would you fail?
... some hold that in those situation the orientation is essential so the exception would apply

Katie: there are specific requirements in VR to prevent nausea (under user safety)
... if safty is involved it would be essential

JF: many situations where smartphone and box makes up the goggle (hybrid solution) - but if covered by exception I'm OK with it

Jason: Do we need a VR example to remove ambiguity?

<AWK> AWK proposes to make a specific example in Understanding to address the VR question or adding a bullet to the definition

Marc: yes we can add that in the 'essential' definition

Alex: Projecting a slide would be a more common exception

AWK: Any suggestions for phrasing tzhat as bullet?
... either put it in definition or in the understanding doc

<marcjohlic> Is this applicable only at launch or throughout the app running

Marc: next Question: only applicable at launch or the entire time the app is running

AWK: Would it fail when turned and orientation remains?

Alex: App or content?

AWK: When the content not locked to a specific orientation
... would you reset or does it do it automatically ?

goverm: 508 refresh has user info not interrupted by the OS - should apply all the time, not just at launch

<marcjohlic> Oracle comment: https://github.com/w3c/wcag21/issues/235

DmD: One comment referring to device mounted in a particular orientation why would it need to support re-orientation?

Jason: If the content has ways of locking the orientation it looks like it should be activated by the user
... if orientation lock is a problem for people they can lock it at OS level or have a control inside the app to lock it

AWK: Oracle's point is the situation where device is mounted and they want access to content that supposes a different orientation

<gowerm> Content is not locked to a specific orientation, and functionality of the content is operable in all orientations, except where orientation is essential for use of the content or is set by a user preference.

Alex: Thoughts on use case of moutned display: when the user locks orientation - some phones home screen won't change orientation
... would it make sense to follow device conventions?

<AWK> AWK: worth noting that in a browser on small iPhone the direction of the device is used in the display

goverm: iPhone position its good to have a dialogue over what constitutes essential
... some users have the device locked in a particular position so they need flexibility

AWK: confirming iphone home screen does not re-orient - so home screen would fail

Jason; We need clarification terminology needs to be clearer regarding the interaction of content / UA / system level

<gowerm> Jason, this is an authoring guide. it refers to authoring content

Marc: it's advice for authors: don't lock orientation - we cannot pick up UA and OS level
... unless is essential
... so we just need to add display orientation and things should be fine

<gowerm> "...operable in all display orientations..."

<Ryladog> +1

+1 to Marc

<gowerm> +1

<marcjohlic> +1

<chriscm> +1

<KimDirks> +1

Jason: specifying that we need a definition of what 'lock' means

<gowerm> Content is not locked to a specific orientation, and functionality of the content is operable in all display orientations, except where orientation is essential for use of the content or is set by a user preference.

Marc: restating: "don't lock orientation in content unless it is essential"

<Joshue108> +1 to Marc

<AWK> +1

<Kathy> +1

<marcjohlic> Please add your suggested definition for "lock" to the comments here: https://github.com/w3c/wcag21/issues/70

AWK: Will revidit on Tuesday

ZaZakim, take up next

Help: https://www.w3.org/2002/09/wbs/35422/COGA_help/results

AWK: less consensus: 5 see significant issues, 3 see minor editorial issues
... Lisa has been on holidays so not much has changed
... concerns were what constituted a long document, a non-standard control
... any additional points?

JF: It looks like we want to cover two issues in one SC: understanding content, interacting with controls - two different problem spaces, should better be split into two separate SCs

mgower: needs scrutiny, going through comments in issue thread and responding to them
... please address comments

Alex: the issue is that there is no one-stop solution to solve the problem - cannot be solved by imposing requirements on authors
... direction seems mistaken

<Zakim> MichaelC, you wanted to address long doc and non-standard control and to address splitting and to say wording intended to allow automated supports

AWK: discussion has touched on killer AT - links to the role of AI

<davidmacdonald> IBM is working on this on the IT side. http://www-03.ibm.com/able/content-clarifier.html

MichaelC: there is a definition long documents that should help - another definition is not yet there
... definition for non-standard-controls - intend is to make this SC workable
... might be split into more than two SCs - could become a 'pillar' - the concept is still a work in progress - attempts to cover the issues related to help / understanding
... putting advice in OR relationships might things easier - but it is a difficult one
... what can we ask from authors? SC tries to say if it is long and complex do something to summarise, clarify
... wording is intended to allow for AI support, but support is not available yet

Jason: seems some agreement that the last two bullets are problematic - to include them you would need to be more specific, or gthey would be moved to level AAA
... there also seems agreement that the distinctions (long/short, simple/complex) are not well grounded now
... no clarity of what a summary would be and whether it should be separate or part of the document
... abstract of a scientific paper would qualify as summary

<Zakim> AWK, you wanted to talk about pillars and "or" relationships

Jason: issues can be addressed but looks like a lot of work is needed - the numerical info and the cardinal directions seem most problematic and should better be moved to level AAA

<JF> +1 to AWK - "Pillars" remains a vague and un-agreed-upon term

AWK: views on what constitutes a pillar are not yet consolidated - better not discuss now. What did MichaelC mean with OR relationship?

MichaelC: would meeting just one bullet option be sufficient - but that is difficult since different bullets address different things
... idea was that if one of the thigs is done at least *something* is done - not clear whether there is consensus on that in Coga TF

AWK: would be easier to implement but people woul draise concerns whether that make ssense

Alex: Still disturbed by the notion that authors should do something because you can - hammer looking for a nail - nothing of that would help, this is not helpful for end users, authors should not be requested to do this
... there are APIs to summaries, to extract keywords, can easily be integrated in personal assistants, even though solutions are not quite ready it should not be fostd on authors

Jason: research says that automatic summaries can noe compete with author-written summaries, so that gives reason for caution
... The problem withe the metadata solution is the potential misuse by authors as already seen in the often incorrect application o dWAI-ARIA

<Zakim> MichaelC, you wanted to say the satisfying outcome won´t be met by SC alone

jason: so we need to be clear what is really suitable and effective for author intervention

MichaelC: Agrees with Alex that proposal does not squarely address needs of users - the attemt was to come up with hooks / starting point, and details would be in the supplementary guidance
... so if there are automatic tools would be available the SC should be automattically met

AWK: will update status of SC on status page

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/06/01 16:32:44 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Present: AWK Davidmacdonald jasonjgw MichaelC KimDirks Katie_Haritos-Shea JF Kathy MikeGower chriscm shadi
Found Scribe: Detlev
Inferring ScribeNick: Detlev
Found Date: 01 Jun 2017
Guessing minutes URL: http://www.w3.org/2017/06/01-ag-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]