See also: IRC log
<Kathy> chair Kathy
<jeanne> chair: Kathy
Kathy: update where we are – We are doing a WCAG 2.1. Nine-month countdown. A lot of work, but fairly good position. We have outline of success criteria. But we have a lot of techniques to write
<chriscm> Hey Everybody. Will join the WebEx shortly, having a couch delivered today and they just showed up.
Kathy: last week guideline 2.4.
Continue with that. Touch pointer feedback, get that finalized
month of June. Work on techniques and failures for that. Work
in parallel on the other guidelines
... it's great to see that we've got a direction – any of the
options they had proposed had pros and cons, there needed to be
some sort of direction now we know and we can move forward. We
have nine months until this gets published. Published before
CSUN
Alistair: how does that work with the refresh version of 508
Kathy: both ADA in US and Section 508 have gone into a delay
Alistair: same with European legislation – seems to be bouncing backwards regularly
Kathy: any questions on where we are
<Kathy> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_revision_of_3.4.1
Kathy: started a conversation last week on screen orientation.
Marc: still thinking of portrait versus landscape – should we make this a success criterion or is it good enough to letterbox in portrait mode, smaller
Kathy: were not saying that you can't lock it in – it might not be the ideal view
Jon: panel app – I don't think that's always enforceable – having scrollbar takes away from piano activity
Alistair: you do have the essential exemption. If it's essential that it's in landscape mode
Jeanne modifying the wiki page as we go
Marc: I like the essential clause – just provide a mechanism to let the user rotated but have the exception for one that developer feels it's essential to keep in landscape mode
Jeanne: would be good to get firm use cases of what we are trying to solve. Not talking about content delivered upside down. We need to come up with clear use cases – that will allow us to settle out the conversation and narrow things down more quickly
Kathy: the only scenario right now is mobile devices are oriented in a fixed orientation. You have it on your wheelchair or an educational setting where devices locked in to a holder
Jeanne: that's clear, but use
cases like piano app
... putting use cases on the wiki page
<chriscm> I'm on and unmuted now! :)
Jeanne: we have exclusions, but do we have examples where people are locking down the content and it doesn't have to be?
Kathy: application where didn't want people to change application and be in portrait even though parts of it could be in landscape mode they made a decision right from the beginning that they only wanted to be in portrait mode – banking website
Alistair: it's to try and simplify design
Jon: even iOS the help screen on the iPhone can only be in portrait mode. It doesn't have to be but they made that is a design decision because they want. the iPad changes, more room on the screen
Kathy: there are examples out there, I think were going to end up seeing more of it
Alistair: it's a usability issue.
You're not going to last long with the bank that doesn't do
things in a way you can deal with so you just end up changing
banks
... you going to sort of automatically rule out some of those
issues by the sheer fact it becomes unbearable to use it
Kathy: not dealing with usable,
just available. It's not usable if they haven't designed it
correctly. We're not saying that it has to be usable. Fine line
in usability versus accessibility
... this is simply you can't lock a person into a specific
orientation
Alistair: set in that context makes it very easy to understand
Kathy: don't lock person in a
specific orientation – should we modify language to that
... stumbling on use of content – content does not override,
website? Are we following a convention here? Does that bother
anyone else?
Alistair: if you lock the screen in an orientation can the content override that?
<jeanne> Propose: Content doesn't force a user into a specific device orientation.
Aliistair: on the old iPad had a lock button. Can content override that? You're talking about the other one which is content locks
Kathy: the application doesn't lock a person into a specific orientation
<jeanne> Content or application doesn't override a user's preference for a specific orientation
Alistair: is describing from the wrong way – what you want is for the application not to lock the orientation for the user
<jeanne> Content or application doesn't lock the device orientation for the user
Kathy: WCAG guidelines are all about content
<jeanne> Propose: Content doesn't lock the device orientation for the user, unless the the orientation is essential to the operation.
<AGarrison> AG: Orientation of the content is not locked to landscape or portrait
WCAG was written before applications
Kathy: how it's written now can apply to everything
<jon_avila> information and sensory experience to be communicated to the user by means of a user agent, including code or markup that defines the content's structure, presentation, and interactions
Jon: WCAG definition of content – that is kind of what were getting at
Alistair: at the end of the day it is the content you're looking for
Kathy: maybe put more in understanding to convey broad meaning of content
Looking at understanding
Alistair: two ideas have been fighting it out in the text – two paragraphs of proposed text for understanding reflect this.
<jeanne> Orientation of the content is not locked to landscape or portrait, except where orientation is essential.
<Kathy> https://www.w3.org/TR/WCAG20/#essentialdef
<Kathy> if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform
<marcjohlic> +1
+1
Kathy: we should come up with a few techniques or failures that we like to list with this success criteria – anybody want to take a stab with writing a success or failure?
Alistair: trouble is – do nothing and it will work, and the only way it won't work as if you actively lock it
Kathy: so failure is device orientation is locked
Alistair: for nonessential use or something along those lines because you've got that essential clause
Chris: I'm working on a blog post regarding keyword accessibility – wrote it on my company's Internet so I may not be able to get it to you till it's released but will keep you posted
<AGarrison> AG: Failure of Success Criteria x due to locking the orientation of content in landscape or portrait, where the orientation of content is not essential
Jeanne: I'm concerned about how we would write a positive technique as opposed to only having negative techniques
Alistair: but the positive technique is do nothing
Jeanne: are there any success criteria that only have a failure technique?
Kathy: in Patrick's comments link
to CSS device adapts information so you can actually set the
orientation on the viewport to auto portrait and landscape. So
positive techniques sets the value to 0. The technique could be
using the orientation to set the orientation to the devices
normal mode – something to that effect
... any other thoughts?
... any other suggestions on this – otherwise send out a
mailing list to get everybody else's feedback
... we will send this out on the mailing list and then gather
feedback to finalize this and move on
Marc: quick comment – tried to jump in and write techniques in touch and pointer, but so much back and forth about the size
Kathy: at least for touch and
pointer techniques will get the feedback first and then write
techniques. in general before we write techniques we should
wait for feedback from the WCAG working group. Hopefully will
be in a cyclical cycle. Some of these we may have to coordinate
with the other taskforces which will also be part of this. We
are working on that – Andrew and Josh are working on...
... a way to help coordinate everybody. That's going to be
critical. Kim and I will work on trying to get that a little
more organized. We're just waiting to see how we are going to
start that coordination.
... we are on a nine-month deadline but we don't want to work
on these and then have to change them.we will probably just
redo the techniques assignment sheet – once we get these
finalized
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) No ScribeNick specified. Guessing ScribeNick: Kim Inferring Scribes: Kim Default Present: Kathy, jeanne, Alistair, Kim, jon_avila Present: Kathy jeanne Alistair Kim jon_avila Chris Marc Regrets: Patrick Found Date: 12 May 2016 Guessing minutes URL: http://www.w3.org/2016/05/12-mobile-a11y-minutes.html People with action items:[End of scribe.perl diagnostic output]