- From: Jeanne Spellman <jeanne@w3.org>
- Date: Thu, 09 Oct 2014 12:44:37 -0400
- To: MATF <public-mobile-a11y-tf@w3.org>
Minutes:
http://www.w3.org/2014/10/09-mobile-a11y-minutes.html
Text of Minutes:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Mobile Accessibility Task Force Teleconference
09 Oct 2014
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2014Oct/0003.html
See also: [3]IRC log
[3] http://www.w3.org/2014/10/09-mobile-a11y-irc
Attendees
Present
Alan_Smith, Detlev, Jeanne, Kathy_Wahlbin, Kim_Patch,
TomB, jon_avila
Regrets
JanRichards, Brent
Chair
Kathleen_Wahlbin
Scribe
jeanne
Contents
* [4]Topics
1. [5]15 minute discussion to talk about techniques
people are working on.
2. [6]Technique Survey (#3 – 6) -
https://www.w3.org/2002/09/wbs/66524/20140929_survey/
3. [7]G85
4. [8]SCR37
5. [9]NEW survey
https://www.w3.org/2002/09/wbs/66524/20141007_survey/
6. [10]G61
7. [11]G53
8. [12]G82
* [13]Summary of Action Items
__________________________________________________________
<trackbot> Date: 09 October 2014
<KimPatch> trackbot, start meeting
<trackbot> Meeting: Mobile Accessibility Task Force
Teleconference
<trackbot> Date: 09 October 2014
<scribe> scribe: jeanne
15 minute discussion to talk about techniques people are working on.
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>
[14]https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Technique_Dev
elopment_Assignments
[14]
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>
[15]https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Mobile_Techni
que_Template
[15]
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>
[16]https://www.w3.org/2002/09/wbs/66524/20140929_survey/result
s#xq3
[16] https://www.w3.org/2002/09/wbs/66524/20140929_survey/results#xq3
[no questions]
Technique Survey (#3 – 6) -
[17]https://www.w3.org/2002/09/wbs/66524/20140929_survey/
[17] https://www.w3.org/2002/09/wbs/66524/20140929_survey/
KW: There are several that were accepted as proposed.
RESOLUTION: Accept G60 as proposed
<Kathy> [18]https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/G85
[18] https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/G85
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.
SCR37
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>
[19]https://www.w3.org/2002/09/wbs/66524/20141007_survey/result
s
[19] https://www.w3.org/2002/09/wbs/66524/20141007_survey/results
NEW survey [20]https://www.w3.org/2002/09/wbs/66524/20141007_survey/
[20] https://www.w3.org/2002/09/wbs/66524/20141007_survey/
G61
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.
G53
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.
G82
<Kathy>
[21]https://www.w3.org/2002/09/wbs/66524/20141007_survey/result
s
[21] 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
Summary of Action Items
[End of minutes]
Received on Thursday, 9 October 2014 16:44:33 UTC