See also: IRC log
I can do it
<AWK> Scribe: Detlev
<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
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
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]