See also: IRC log
<trackbot> Date: 09 October 2014
<KimPatch> trackbot, start meeting
<trackbot> Meeting: Mobile Accessibility Task Force Teleconference
<trackbot> Date: 09 October 2014
<scribe> scribe: jeanne
KW: The WCAG conversation was
about using terms that refer to a specific device. We should
avoid words like "mobile" and reference it specifically. We can
say "on a device"
... That's for General Techniques and HTML Techniques
... when we get to the mobile techniques, then we can use
mobile.
... I will look back through the ones we have already
done.
... Kim has been going through the Techniqes specific to
mobile, and we will send them back to WCAG if they need
updating.
... we will get further direction on that when it is ready
<Kathy> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Development_Assignments
KW: We want to get Techniques
written that are specific to Mobile before the 18 Nov
deadline.
... please take assignments from that list, so we are also
releasing Techniques that are specific to Mobile.
... also pick the ones that are most important or higher
priority for developers to know.
... I want everyone to do at least 1 before the Nov deadline,
so they will get into the next publication.
... if you are not comfortable with writing Techniques, if you
need support, we can work on parts of that during the meeting,
or pair people up.
<KimPatch> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Mobile_Technique_Template
KP: There is a Mobile Technique template
KW: Any questions on current Techniques/
<Kathy> https://www.w3.org/2002/09/wbs/66524/20140929_survey/results#xq3
[no questions]
KW: There are several that were accepted as proposed.
RESOLUTION: Accept G60 as proposed
<Kathy> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/G85
<AWK> all of the differences are marked with @@?
KP: I see one use of the word "mobile"
JA: We could use "small screen device" because the error would not be visible onscreen.
KP: What about vibration? This is a very specific instance, and it is strange to think of a device with vibration that isn't a mobile device.
It could be a wearable with vibration
AWK: What does the vibration have to do with this Technique.
<Kathy> For example, for a device with a smaller screen an inline error may be displayed to indicate that an error has occurred.
<Detlev> Suggested changes, Examples, fourth bullet: may be reformulate to: "Client side scripting @@@ or native error handling @@@ detects the error and modifies the document to provide a text description next to the form fields with the error." Third bullet point can then go.
Detlev: The bullet points look nearly identical. Include the option that HTML5 native error handling may also be a part, but I don't know if we need to cover it because it is not a mobile-related change. Perhaps this should be passed back to the working group.
KW: I think since we have already done it, let's continue to send it to WCAAG, but if they disagree, we should remove it and not make further changes.
JA: Not all mobile devices are supporting HTML5 error handling
KW: We could take it out since it is not specific
JA: Do we have alerts covered if we remove it? It seems to be covered in 1.
DF: Since you didn't put something in a required field, it would give a popup or message that handles the error client-side.
JA: I agree, we don't need to force one
KW: Agree to remove example #4
DF: My suggestion is to add "native error handling" and remove the phrase on submit, because that is no longer necessary to the Technique.
<AWK> suggest: The client-side scripting or native error-handling also modifies the labels of the fields with the problems to highlight them and sets the focus on the first error.
AWK: The one thing about the 4th bullet, that is moving the focus to the first error, that should be moved to the 3rd bullet
JA: If we are thinking about a situation with bullet 4 simply as you tabbed around.
KW: We were thinking of mobile device without a list of errors at the top of the screen, so we were thinking about how to display error messages on a small screen.
JA: An example of the user
exiting the field with the validation done at that time, with
focus returning to the field.
... it isn't unique to mobile. It would take more scrutiny and
need more agreement if we did put it in?
AWK: Either way works for me. There is an error, and when the user moves focus away from that field, it displays the error and moves the focus back for them.
DF: I would also change "and moves on to the next field" instead of Submit
JA: We are morphing the example
and moving away from the user Submit the form. We need
both.
... so we can change bullet 3 back to the server side
scripting
Alan: putting the @@ around the modified text really helps us to see it.
JA: I think we need to send this back for more work?
KW: We will leave this and Jon will write a new example.
KW: Jan hadsuggested leaving it open and suggested it be left motile
KP: Can we say "swipe gestures" so it is less necessary to say mobile
[agreement]
KW: ARe there some proposaed changes?
<KimPatch> should remove (including mobile devices)
JA: #3 says the dialog is next in the focus order, or we could say, focus is moved
DF: That's the same thing - one is developer viewpoint, other is user.
Alan: would a reading focus make a difference?
jA: There has to be a way of
closing the
... dialog box. I don't know how specific we should get. There
are many ways to handle it.
KP: should we note the change?
KW: We have to keep a clean copy for WCAG. It should go in the Notes
KP: The History is good to keep track so we don't repeat the same discussion later.
JA: The View History page in the wiki will show who updated the page and what was updated
KP: But it is harder to do
it.
... it's a matter of what is more important. If we don't need
it, then clean it up.
DF: I wonder if we need to include the closing part which talks about closing in a device-independent way. IT isn't in the Test Procedure now.
KW: The description is very
keyboard focused.
... if we are going to change the other language, which should
also fix that it isn't a physical keyboard.
JA: It has many other issues that go beyond mobile that need to be addressed?
KW: AMK, should we send this to WCAG?
AWK: Yes, that should work. It
would be helpful to point it out and WCAG will ask for someone
to amend it.
... we won't tell you not to make suggestions beyond mobile
JA: I want us to focus on mobile than try to fix all the issues around forms and dialog.
DF: I think we should include swiping for gestures?
KW: I think it has more issues.
DF: I will make a list of things we should change. Others can make suggestions to what else needs changing.
KW: Put it in the status area up
top, and list suggestions for WCAG WG to address.
... we are trying to make sure it doesn't exclude mobile. We
want to look at it in a device independent way that doesn't
exclude mobile.
<Kathy> https://www.w3.org/2002/09/wbs/66524/20141007_survey/results
DF: Do we want to include something on small screen that changes orientation? It changes order.
KW: It doens't change order in that orientation
<jon_avila> Did we finish talking about g53 from the prior survey?
KW: We do have a phrase that includes orientation
RESOLUTION: G61 is accepted as proposed.
JA: The purpose of the technique, is that the focus stays on the link while reading the context. I don't know any way that would work on Android on iOS.
DF: That is correct. You have to move the focus and bring it back. It is easy for an experienced user, but it is true.
KW: We could add that to the user notes.
[group agrees]
<Detlev> +1
<Alan_> Sorry, I had to step away for a few minutes, I'm back.
RESOLUTION: G53 accepted as amended.
<Kathy> https://www.w3.org/2002/09/wbs/66524/20141007_survey/results
DF: The description of the Canvas game sentence didn't make sense to me.
G82 is amended according to comments on the survey
KW: Reminder to work on new mobile Techniques so we can have some on the next WCAG release.
<Detlev> bye
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Jan had /KW: Jan had/ Succeeded: s/ harder to do it?/ harder to do it./ Succeeded: s/ G87 is amended/ G82 is amended/ Succeeded: s/RESOLUTION: Accept G60 and G53 as proposed/RESOLUTION: Accept G60 as proposed/ Found Scribe: jeanne Inferring ScribeNick: jeanne Default Present: Kim_Patch, Kathy_Wahlbin, Alan_Smith, TomB, Jeanne, Detlev, +1.703.637.aaaa, jon_avila, +1.617.766.aabb Present: Alan_Smith Detlev Jeanne Kathy_Wahlbin Kim_Patch TomB jon_avila Regrets: JanRichards Brent Agenda: http://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2014Oct/0003.html Found Date: 09 Oct 2014 Guessing minutes URL: http://www.w3.org/2014/10/09-mobile-a11y-minutes.html People with action items:[End of scribe.perl diagnostic output]