View source for New WCAG 2.0 Techniques

The following proposed techniques and best practices are missing from WCAG 2.0 for mobile web and applications. 

Minutes where discussions took place:
 
[http://www.w3.org/2014/05/16-mobile-a11y-minutes.html Minutes of 16 May] Questions 1-3

[http://www.w3.org/2014/05/30-mobile-a11y-minutes.html Minutes of 30 May] questions 11-14

[http://www.w3.org/2014/06/06-mobile-a11y-minutes.html Minutes of 6 June] Questions 13, 4-10

[http://www.w3.org/2014/06/20-mobile-a11y-minutes.html Minutes of 20 June] Questions 15-20

[http://www.w3.org/2014/06/27-mobile-a11y-minutes.html Minutes of 27 June] Questions 20-25

[http://www.w3.org/2014/07/11-mobile-a11y-minutes.html Minutes of 11 July] Questions 25 & 27

[http://www.w3.org/2014/08/01-mobile-a11y-minutes.html Minutes of 1 August] Questions 29 & 30

Questions 31-35 - all notes were entered in [[New WCAG 2.0 Techniques]] table.

===Applicable to Mobile Requires Changes===

{| class="wikitable"
|-
! Technique Title (draft) !! Description !! WCAG 2.0 Success Criteria !! Applies to !! Discussion Notes 
|-
| 1. Ensuring that images used as controls have sufficient size for touch (survey #29)|| Images have to be above a certain size i.e. 29px by 29px (resolution based) and below a certain size i.e. 480px x 320px (resolutions based). || Best Practice || Mobile Web & Native Apps || see http://www.quirksmode.org/blog/archives/2010/04/a_pixel_is_not.html
|-
| 2. Relationship to other W3C Mobile specs || Some mobile related technologies, such as Web Event for touching the web, Geo_Location for positioning the web, Vibration API for waving the web, and Network Information API for connecting the web.They would be helpful to improve the accessibility of Mobile Web and Mobile Web Application. || Best Practice || Mobile Web & Native Apps || What might be needed in the future are Input-specfic Success criteria under Guideline 2 Operable beyond Keyboard access, such as "Touch Accessible: Make all functionality available from a touch screen".

Note however that others disagree that WCAG should be extended to cover input-specific success criteria in the vain of 2.1.1 Keyboard - see [http://www.incobs.de/articles/items/implications-of-new-input-modes-touch-speech-gestures-on-the-web-content-accessibility-guidelines.html Implications of new input modes (touch, speech, gestures) for the Web Content Accessibility Guidelines]
|-
| 3. Using infomation available via mobile sensors as default || Automatically filling in information if known (location into a form field) ||  Best Practice || Mobile Web & Native Apps  || 
|-
| 4. Define hover, focus & selected || Define the hover, focus, selected and touch (regular, long) states || Sufficient Technique 2.1.1, 3.2.1 or 3.2.2, UAAG 1.3 || Mobile Web & Native Apps || incorrect use could cause failure; needs to be further defined, see https://hacks.mozilla.org/2013/04/detecting-touch-its-the-why-not-the-how/
|-
| 5. Touch target size (survey #29) || merged with survey #29 below|| Advisory Technique 2.1.1 - but better as a new guideline || Mobile Web & Native Apps || Touch Accessible: Make all functionality available from a touch screen
|-
| 6. Separate interactive elements by a space to facilitate activation by touch (survey #30)|| Spacing requirements ||  Best Practice || Mobile Web & Native Apps  || Need to define what the space requirements would be - REVIEW LATER
|-
| 7. Activating elements via the touchend event (survey #33)|| Interactive elements should respond to the touchend rather than the touchstart event -- with exceptions for controls such as on-screen keyboard keys and direct touch controls. || Advisory Technique 2.1.1 or 3.2.1 or Best Practice || Mobile Web & Native Apps || 
|-
| 8. Use of enhanced contrast (survey#28?? this one may have been dropped inadvertently)|| Use of enhanced contrast: Mobile devices may need higher contrast most of the time, Items are smaller may require more contrast (18pt or larger is smaller on mobile), Support for alternative input mechanism on devices that do not have or support a physical keyboard / equivalent access for keyboard || Already a technique WCAG 2.0 1.4.6; think about whether the more strict contrast 4.5:1 applied to all elements || Mobile Web & Native Apps || Discussion: Potentially break this into multiple techniques. Could also be a failure. Can control device in many ways. Qualification: if you can't connect to a device, you won't use it. Certain requirements that can't be met and you can't claim them, example audio description. Concern: can you claim conformance if platform doesn't support, for example keyboard. Default interaction is keyboard, so keyboard access is basic. On mobile the model is shifted. Primary input on most devices is primarily touch and gestures. In redefining what keyboard access is, Indie spec doesn't matter how you get there. What input is going to be required on a mobile device? We could take a functional approach, saying that we have to have an alternative method that can be used by all of the following groups: an alternative method that doesn't require speech, an alternative method that doesn't require touchscreen, unless it has an accessible touchscreen feature – we could define it from a functional aspect. Whatever alternative is accessible to the largest group of people. Historically keyboard access because you can control with software that can mimic the keyboard. I don't know that we can rely on that and mobile. Functional approach? Keyboard is the most universal device. Is that model still true on mobile? Can everything be accessed with touch and gestures? Not on iOS unless you rely on voiceover? You still have to have a programmatic element, and determine what is an active control. Getting more towards the IndieUI model.
Potential solution: an alternative method of interaction would be something that is programmatically exposed and accessibility supported, meaning technology that uses that programmatic interaction to provide access to it. Whatever interactions that could perform, you could provide them programmatic we could provide some way and that would include keyboard access. We could include examples. Failure: if it doesn't support keyboard? You could make an argument either way based on the accessibility supported. Failure of device and not of app?
Action: get more feedback on this proposal from other groups. Take it to UAAG working group, has a lot of language around this)
|-
| 9. Provide clear indication that elements are actionable (survey #2)|| Provide visual/audio indication for all functions || New Technique? || Mobile Web & Native Apps || Discussion: This means how do you know something is something you can interact with on a device. First whether something is interactive or actionable, second whether there is an accessible equivalent for audio and video. Not sure whether everything needs to have audio, because if it's done programmatically features can be announced to user. Is it audio and video or audio or video? Basic requirement is provide indication that something is actionable. A lot of times where you have no idea the something is actionable. 
|-
| 10. Provide instructions for custom functions and gestures (survey #3)|| Provide instructions for custom functions and gestures || Sufficient technique WCAG 2.0 3.3.2 or 2.1.1 || Mobile Web & Native Apps || Discussion: Are instructions different than advisement? Same as HTML as make under 332? But is this more for input? Instructions like those in keyboard trap? Map to 211 keyboard access? Less input than the interaction requires it. Is this an accessibility issue? If you have to use a custom function or gesture and can't access it in another way that it is keyboard issue, and it is an accessibility issue because you have to reformat gesture. If you can perform in multiple ways, then more of a usability issue. Example gestures for expanding different areas swiping up/down – need to be able to do those gestures in order to perform that action. Android toolbar, can't have more arrow, but can press control be to turn on bolding. User must be advised that control be turns on bolding on this particular app. Technically you could argue 211, but functionally the user is not aware of that, so keyboard trap. It's not instructions for custom functions and gestures, but provide keyboard support – alternative input method – for custom functions and gestures – it's the alternative input method that's the issue. User must know it's there – it's the documentation, just like a keyboard trap. 
Potential solution: The user is advised of the alternative input of custom gestures and functions when alternative is not available with standard input method. Sufficient technique, but also a failure
|-
| 11. Specify input type for numerical or character data (survey #4) || Specify input type for numerical or character data ||  ||  || 
Discussion: Too general? What should the boundaries beyond this? HTML 5 semantically meaningful  input types. User agents need to be smart when they cause keystrokes to be ignored. Maybe even a note. For example if you're only listening for numbers and the letters are ignored, the user needs to be notified of that. Collecting a date, what's the format? If specific to HTML 5 and then reference the data format for a reference technique, that would cover it. Technique under 1.3.1. What about mobile apps, Native apps rather than HTML 5. We can tell it  to show us a specific keyboard. Problems with speech and voiceover users not giving the computer with the computer expects. 1.3.1, but if we get into the labels and changing instructions that goes into 3.3.2. Maybe we need multiple Techniques here. Both a mobile issue any desktop issue. Mobile: brings up a numeric keyboard instead of the numbers, extra step to switch to numbers. May be more of an issue for mobile. 
Actions: Look at sufficient techniques under 3.3.2 and add in something specific to mobile about extra step and speech and screen reader issues. This will be broken down into two will likely require multiple techniques specific one for apps, which affects keyboards.
|-
| 12. Supporting the characteristic properties of the platform (e.g. zoom, larger font, captions) (survey #5)|| - || New Success Criteria/Best Practice ||  ||
Discussion: Make this more specific. The technique will be very granular – BBC method how do you program this in iOS, how do you program this in android. Windows phone high contrast is programmatic, while others take these whole screen and convert it. Break into two separate ones or keep together? Differences between platforms would be hard to maintain. Handle it the way BBC does? There are sufficient techniques for resizing text and having captions but the techniques are not about honoring settings that have already been set in the operating system. You could just go out and burn your own captions onto the video and that would be fine. Difficult to map to a success criteria. What this is really saying is if the platform had set these flags that let's the preferences of the user known, should pay attention. More like Section 508 type thing. UAAG's job would be to pass through the platform flag. Firefox for the android would see that flag and make sure to play captions for any content. But it's up to the web content pick up that message. This is an important technique especially as we are getting user settings in the cloud. This might be a hole within with WCAG – consider new technique?
Action: Jan – can generic refer to flags the browsers and apps can set – will look.
|-
| 13. Seting the virtual keyboard to the type of data entry required (survey #6)||  (e.g. date picker, email keyboard with @ sign) ||  ||  || 
Discussion: Barrier or inconvenience? UAAG2 overlap in app world calling your own keyboard. This technique is specific to apps because we already have the one about HTML 5 type. This would be specific to native applications. Advisory technique under keyboard access or 1.3.1, or 4.1.2? Doesn't have related success criteria, and potentially something that we should consider down the road.
|-
| 14. Positioning important page elements before the page scroll (survey #7)|| - || Best Practice ||  || 
Discussion: Page scroll very a lot based on device. Many different factors, screen size, browser, chrome height, resolution, difficult to test without specifics. Usability rather than accessibility? Best Practice (something that doesn't map to a success criteria, and we wouldn't want to map to down the road). It's not exactly reading level, but it's that type of thing 3.1, but it's not really. It would have to be AAA if we did something down the road.
|-
| 15. Grouping elements that go together (e.g. link icon with link text) (survey #8)||  ||  ||  ||
Discussion:  This one is the technique from BBC. H2 sounds similar. Implicit proximity relationship that kind of gets around this. Situations where you have a check off and then if you check that box it wakes up a second box right after it that you need to fill in because you check that check box – situations like this need grouping. Toolbar icons grouped, and grouping links together 1.3.1. The same could be also for parts of the image that make up the image as a whole. Is this already covered under WCAC, but we want a mobile example too? Is there anything not already covered under WCAG techniques.
Action: Verify that this is covered under WCAG techniques and add mobile example
|-
| 16. Keeping the page banner short to avoid unnecessary scrolling (survey #9)||  || Best Practice ||  ||
Discussion: Similar to #7. Came out of FunKa Nu. Not huge problem.
|-
| 17. Placing buttons where they are easy to access (survey #10)||  || Best Practice ||  ||
Discussion: FunKa Nu has very specific guidelines. Do not place at the right/left edge unless they take up at least one third of the width of the screen - Do not adjust buttons, functions or groups of buttons and functions to the right unless the group of buttons/function extends over at least 75% of the screen in all positions. Problem with that one third of the width of my iPhone is very different than one third of the width of my iPad. Aimed at one-handed use. Lots of usability studies relating to what's hard-to-reach versus easy for the majority of users. This would make it more difficult for some users to interact especially because we're talking about primarily touch in mobile situations. Is this a best practice or should we have this as an advisory tech? Leave as best practice.
|-
| 18. Position form field labels above the field (survey #11)||  ||  PLACEHOLDER ||  || 
Discussion: above versus to the left, adjacent, different in portrait versus landscape

Solution: already advisory for SC 3.3.2 and covered by G162
|-
| 19. Adapting the length of link texts to viewport width (survey #12)|| Link lengths should be adapted to the screen width ||  PLACEHOLDER ||  || 
Solution: Long link length covered in SC 1.4.8 - so keep this as best practice
|-
| 20. Design actionable objects to look actionable (survey #13)||  ||  PLACEHOLDER || Note: This one is done, have to transfer notes || 
Discussion:
Important issue - iOS has included an option to make buttons look buttons and not flat objects.
May be more important on mobile because there is no hover and not always a way to reach it with the keyboard.
Mobile settings – iOS 7.1 turn button shapes on and links get underlined, selected tab has blue shading.

Suggestion: make all focusable object meet the design standards of their platform

Issue: standards change

Suggestion: could say don’t suppress something that is actionable
Issue: difficult to make a test for buttons, links would be easier, and pushback from developers who say they can’t modify the look of the button

Action: Jeanne and Kathleen and Alan will talk further and come back with a suggestion
|-
| 21. Ensuring pages support both portrait and landscape mode (survey #14)||  ||  PLACEHOLDER ||  || 
Discussion: Important for people with fixed orientation such as when device is in wheelchair.

Issue: hard requirement may affect design of games and may get push back

Possible solution: user interface has to operate in both orientation to the extent that the user can escape from the orientation and that it doesn't have to fully operate in both orientations.
Maybe split into two levels with this being the first and the second a high level one that requires functionality to work in both.
|-
| 22. Using simple navigation concepts with consistent interaction patterns (survey #15)||  ||  PLACEHOLDER || PLACEHOLDER || 
Discussion: Often with responsive desing, nav mechanisms do change. Would orientation be a problem? Would orientation be a problem? If it's broken for everyone, then its not accessibility related. Within that view, you need consistency. Idea of conformance claim to just one responsive version. From evaluation methodologies mtg. Whether different versions are different. EM group will say that different responsive design versions are NOT different versions...just different states. Base on progressive enhancement, not responsive design, different, but it becomes a lot to test.  Even the designer has catered for different versions with queries etc then those versions should be covered as states for the test.

RESOLUTION: #15 is that we would map to 3.2.3 and 2.4.5. Put in mobile note on consistency within a viewport size. No new technique, we can incoporate into other techniques

|-
| 23. Allow users to interact using device buttons  (survey #16) || Allow users to interact using device buttons (e.g. arrow keys, ok button ||  PLACEHOLDER || PLACEHOLDER ||

Discussion: Some respondants say advisory and others say sufficient techniques  UAAG crossover? 
Make a note in the technique about device buttons 
May want to widen device buttons to include other input mechanisms such as shaking, etc. to dismiss or undo, some of these are device specific. 
If the device allows a gesture or physical buttons they should be supported? 
Not sure if we want to stop at button or include other potential input mechanisms. May need a refererence to IndieUI 
Concern over allow it to meet a SC without providing other types of access beyond just this gesture.
 
RESOLUTION: Advisory technique under 2.1.1
|-
| 24. Ensuring that the interface can be used with a bluetooth keyboard (survey #17)||  ||  PLACEHOLDER || PLACEHOLDER || 
Discussion: Modify way it's word. If it's supported by the platform. Maybe changed bluetooth keyboard to input devices. Also USB to go to connect USB. 
Ton of bluetooth devices that would get included - never ending stream including switch devices - alot to test.
Could add a mobile note to current keyboard techniques. Could be different devices based on what you have identified as accessibility supported. 
Set base level of accessibility support on a particular device with keyboard., theoreticaly example. 
If we look at creating a new one or incorporating, what is preference? 
G202 is a general keyboard technique that might be used. 

RESOLUTION: Add note to g202 about other external devices. Add in notes about support for device or bluetooth device.

|-
| 25. Adding shortcuts to allow users to jump to sections of the page (survey #18)||  ||  PLACEHOLDER || PLACEHOLDER ||
Discussion: Perhaps app would be different. Could use app specific things like heading traits 
Keyboard shortcuts covered under advisory already as future link under 2.1.1. 

RESOLUTION: Advisory technique to 2.1.1
|-
| 26. Providing a way for users to change font (survey #19)||  ||  PLACEHOLDER || PLACEHOLDER || 
Discussion: Sounds like UAAG. Should be part of browser and OS not developers responibility 
Concern over lack of support in current devices. Could perhaps be an advisory technique or best practice for current state -- it would be good if user agents did this -- but most mobile devices are not doing this. 
Some apps like Pocket allow this I think. Could we point to UAAG and then say if device doesn't support it. Are we talking about font size, color, font face, etc. 
UAAG 1.4.1 http://jspellman.github.io/UAAG/UAAG20/#sc_141 
Additional settings in apps are welcome to users with low vision because settings do not propogate. 
What is the benefit of font type? People with dyslexia 
c22 is a technique that talking about using CSS to control presentation.
c22 is advisory for 1.3.1 and 1.4.4.  
Technique for native apps more than web apps? 
Put in c22, but also have a style switcher technique as a best practice or advisory, etc. 

RESOLUTION: advisory technique for 1.4.4 or 1.4.8 to adjust visual presentation on mobile through a style switcher

|-
| 27. Providing support for alternative input mechanisms (survey #20)||  ||  PLACEHOLDER || PLACEHOLDER || 
Discussion: We have already talked about this issue and IndieUI. If IndieUI was supported, that would allow this to be met, but if you didn't use a device independent method, you would have to work with these versions. There would be other ways to meet it with the platform, like iOS Switch Access. Duplicate of #1 

Resolution: Duplicate 

|-
| 28. Ensuring that navigation works on different screen sizes (survey #21)||  ||  PLACEHOLDER || PLACEHOLDER || 
Discussion: It goes beyond WCAG, i think it should be a best practice. I'm not sure what we are solving. It is blocking responsive design, it could increase problems for people with low vision. I could see same navigation across orientation as a best practise for people who are targeting an audience with certain cognitive disabilities. 
This is from the Funka Nu gap analysis. 
2.1.1 for keyboard 

Potential Solution:
|-
| 29. Provide a way for users to see what page they are on (survey #22) || ||  PLACEHOLDER || PLACEHOLDER || 
Discussion: Comments from Jon and Detlev recommend it as sufficient technique under 2.4.8 AAA 
Recommend tighting up the wording 

RESOLUTION: 22 as a Sufficient technique under SC 2.4.8 AAA and fix the wording when we work on it.

|-
| 30. Use vertical navigation (survey #23) ||  ||  PLACEHOLDER || PLACEHOLDER || 
Discussion: What is meant is "Provide vertical navigation mechanisms that work without horizontal scolling on narrow width screens )which I admit may be too wordy)" This is important  for people working with fixed orientation portrait mode. I can't see anyone doing this because it would cause such a bad user experience. I don't think we should add something to the guidelines for unique cases.

RESOLUTION: drop #23
|-
| 31. Provide links with the page contents to key pages (survey #24)||  ||  PLACEHOLDER || PLACEHOLDER || It was already in 2.4.5
... are there any things that are different for mobile?
... can we say this is already covered under 2.4.5?

RESOLUTION: Sufficient technique already covered under 2.4.5

|-
| 32. Provide the open/closed state information in the menu icon (survey #25,26)||  ||  PLACEHOLDER || PLACEHOLDER || 
Discussion: They should be more generic – anything that has a state should be described generically. From a designer perspective this is something that people are getting away from. It makes a good example because in the mobile space it is popular right now. How to make it more generic? Open/closed state Or Open/closed of an icon. Really more of a hide/show.  The problem is when you're exploring this element you don't know what the state of the other thing is. If it's showing, hide its hiding, show. Act here and result shows up somewhere else. Maybe provide hide/show state and give several examples. Responsive design examples? Multiple tabs, some hidden? Anything that has a high show state, we want that state to be communicated. In native world you don't have aria expanded. Tab 2 of 3 selected. Also click a button, have something slide out from the right. Another example in iOS is the page indicator. Four dots that represent four pages. Native apps same issue – technology specific technique or general technique? General is if it has a toggle you need to know what stated is. Specific technique is going to be different depending on iOS and android, web, Windows 8.

Resolution:  Make more general to provide the hide and show state and sufficient technique under 1.3.1  and 4.1.2, also provide sub examples.
|-
| 33. Ensure that menu can be zoomed to 200% (survey #27)||  ||  PLACEHOLDER || PLACEHOLDER || 
Discussion: In OS X this is a significant issue because you can't zoom the menus independently, the workaround was to magnify the entire screen, which in some cases worked effectively, in other cases didn't. Problems with overlays or modal dialogs when you try to pinch and zoom on mobile web. Native applications don't tend to resize anyway, because it's fixed point size so relies on the native device itself, so it's covered on operating system. Either pinch and zoom or double tap to resize content. Is this truly a technical issue with Menus that we need  to address? Modal dialogs are also an issue and may be need to be addressed. Specifically mobile web in the actual navigation menus that are part of the webpage and the dialog windows as well. It can also apply to native apps, but it's not going to be pinch and zoom, it's going to be native controls which is not going to be a problem. So this is specifically a native web technique. UAAG crossover – requirement trying your best to reflow so there's only one movement up/down. Should the user agent, but problem is that pinch zoom is not working for menus and dialogs. Are we saying do your best to reflow here? Content may resize but the menu, it's an overlay Or drop-down, may scale at different rate. Guideline should be page rendered larger, but consistently, including overlays and menus.  We need the page scale at the same rate or consistently, WCAG 1.4.4.  One of the ways that can be met is– dumb zoom, don't want to go 200% left and right and up and down, just Want to make the text bigger, but all kinds of things happen, container, scrolling, all sorts of bad things. Do we want a text only zoom? When you pitch a page in a mobile browser if there's menus open or something overlaying the screen, in that pinch everything skills consistently. That's a first point. The second point, which 1.4.4 addresses is I can set a default text size for the body text, and it independently of my pinching to zoom should just grow the size to text, and when I pinch it should grow the text relative to everything else. So pinch is universal, but independent of that there needs to be ability to make text larger, 3x or whatever.  So dumb zoom  works, but the problem is when text is set larger problems with containers etc. Better name or fit into existing techniques with new example? Text resizing exists, dialog boxes, menus don't.  1.4.4, failure for that which is F 69 – associated with just increasing text size, not just dumb zoom. Maybe expand resizing generally, then below that two phases. Is this the right place to put it – maybe more emphasis on the zoom feature. Especially the mobile guideline raising the – having a top-level line item that talks about  zooming in magnification is important. Can't change wording, modify or new technique. Gavin will research. Also 200% may not be enough for mobile. Advisory technique about going beyond 200%?  Minimum font size?  Color contrast ratios for mobile? Is this relevant for mobile and were talking about smaller screen sizes – This is another point Where we need a new discussion. Might be color contrast ratio but if we have a Mobile multiplier for 14 point number because you're holding it closer to your face, then we can say a percent of desktop. 10.1 tablet is a mobile device but a desktop size – need to be careful about how we categorize device class. Maybe a table with viewing distance.

Potential Solutions: Sufficient technique under 1.4.4 but specifically adding two F 69, Modify to say resizing in general not just text resize. Or new technique, because so important for mobile. Advisory technique about going beyond 200%? Also what's the minimum font size that should be done. Two parts to that – points or pixels, and pixels very by resolution. Charge that relate viewing distance to points – with mobile you are holding it closer. 
Jan will do research on Viewing distance table.
|-
| 34. Ensuring that links and other actionable elements are clearly distinguishable (survey #28)||  ||  PLACEHOLDER || PLACEHOLDER || 
Discussion:
Make more clear – element that's distinguishable as opposed to the action. Words just sitting on the screen, can't tell If it's a link, or can't tell that you can swipe it. Lots of elements you can swipe that don't have a visual representation on-screen. Maybe that's a separate thing with separate techniques. It's vague and difficult to test. As a designer if the UI elements labels are vague you are stuck. If you do something custom, the onus is on you. It's both the platform and the designers responsibility and it's hard to test. If we did this as an advisory would there be a risk that there's something we can't test? Don't suppress the platform behavior is testable. Suppress the platform behavior, not testable. Advisory – we shouldn't suppress the platform? Shouldn't suggest that, but should be identified correctly and replace that With something you might feel is even better. Concerned about the idea of change in the platform default – good to be able to break the rules and do it better, then encourages people to be creative and move things forward but still maintain accessibility. Doing something custom is fine as long as is distinguishable. Make sure it's clearly defined role, make sure enable platform to render it correctly, and alternatively if you want to render yourself that's fine too, but you have to make sure it's clearly distinguishable. I agree but two techniques – one is not to suppress and the next Make custom distinguishable. WCAG 1.3.1. Could add mobile example and that's a sufficient technique.

Potential Solution:
Two techniques. 
1. Advisory: you shouldn't suppress the platform default 

2 Sufficient: Make sure a custom treatment is distinguishable.

Action: Look to see whether we should include in WCAG 1.3.1 as a sufficient technique or create a new technique. Think about separate technique for swiping, pagination.

|-
| 35. Ensuring that touch targets are large enough to touch accurately (survey #29) ||  ||  PLACEHOLDER || PLACEHOLDER || 
Discussion:
It could fall under keyboard access, being able to activate an element falls under keyboard. But that's via a keyboard interface. Ironic because keyboard access means a touch target doesn't need to be large. Text resizing is the only one that mentions size. When we talked about keyboard access overall we talked about more general IndiUI. We need to think more broadly because WCAG doesn't take into consideration – just keyboard and mouse and now we have all these other methods. Mobile device touch is the native input. Some don't require touch at all – WII or game systems, idea of touch targets there is weird. Advisory techniques are just one way to meet the success criteria. Refer back to the platform guidelines here? Further research to figure out whether we want to have it in here. This is important for mobile and an accessibility issue but it might not fit with WCAG. 
Anecdote: page indicators on the home screen and voiceover, idea was get close to it and then swipe to get to that small element rather than you have to touch everything on the screen. 
UI for controlling complex machine, touch targets everywhere, hundreds on screen very small, but if you have zoom you can do what you need to do. May be this is just a usability best practice. Minimum sizes is an accessibility issue. Zoom might not be enough – high cognitive load. Maybe get more discussion on should we have more on minimum sizes for things. Advisory under 1.4.4, resize text? That's the closest, there isn't really a WCAG success criteria that's the same.

Potential Solution:
Action: further discussion, potentially Advisory under 1.4.4, resize text

|-
| 36. Providing an inactive space around actionable elements (survey #30)||  ||  PLACEHOLDER || PLACEHOLDER || 
Discussion: Adequate space around so you are not activating two elements at once or overlapping touch Zones.  Examples where this doesn't work? Weather app, no padding, perfectly functional. Don't want to force this if it's not necessary. Example: Educational product, days of the week, just first letter, can't touch one of the letters to get to that  days assignments because there's no padding. Almost seems like the solution is number 29 which is to make the touch area easy to touch, but adding padding doesn't necessarily follow. If they were following 29 you would need 30. 29 takes care of it just by virtue of a putting a minimum. If we have adequate touch size it doesn't matter but the spacing is  between them. If 29 were made in new success criteria 30 can be a sufficient technique, but that might confuse things. As a corollary, do we want something around how to represent blank space. How do you tell user that there's dead space? Moving their finger and hearing nothing and don't know that there are two little items on the Screen? Should blank space be described in certain cases – you know it's doing something as opposed to rubbing your finger on the screen and hearing nothing. Better understanding of screen.

Potential Solution:
None – 29 is sufficient. Adding discussion on blank space.
|-
| 37. Ensuring that platform zoom functions are not supressed (survey #31)|| Where zoom is supported on the platform it must not be suppressed ||  PLACEHOLDER || PLACEHOLDER || 
Discussion: This is about responsive design – are there other situations where Zoom can be suppressed?
No one can think of any.

Potential Solution:
Either sufficient technique or mobile example to the technique for magnification? Falls under 1.4.4 as sufficient technique
possibly example to this Technique [http://www.w3.org/TR/WCAG20-TECHS/G142.html G142]
|-
| 38. Using Standard operating system alerts where available (survey #32)|| Standard operating system alerts must be used where available ||  PLACEHOLDER || PLACEHOLDER ||
Discussion: Agree with Jan on the survey that you wouldn't need. We're talking about alerts on the page, pop-up, not system alerts. What this technique is saying is you should do the standard way of doing alerts rather than custom.
We should do more research on this one  – it should be a best practice of anything, but I would want to know why we are doing this.  It's there, we know how to use it and it's accessible, but do we want to force people?

Potential Solution:
Best practice

Action:
more research – why

|- 
| 39. Activating elements via the touchend event (see above) (survey #33)|| Touch events must only be triggered when touch is removed from a control ||  PLACEHOLDER || PLACEHOLDER ||

Discussion: Causes issues on some sites. It's all about when the event is triggered. When I touch and element it does something immediately – should never force a user into doing an action, so you don't want to do it when you first touch it, rather do it when touch is removed. Triggering touch events on first touch is really done, but it does cause an issue. Similar to mouse events on a webpage – if you click and don't want to do that and you keep holding it down and slide off you can avoid doing that. So same with touch.

Potential Solution:
Sufficient technique under success criteria 3.2.1
|- 
| 40. Providing media metadata (survey #34) || Metadata should be provided for media ||  PLACEHOLDER || PLACEHOLDER ||
Discussion:  What does this refer to for mobile? This was from BBC's guideline: http://www.bbc.co.uk/guidelines/futuremedia/accessibility/mobile/audio-and-video/metadata
There's a technique that says you can use link to the text version of it. This is specific to multimedia. This would be similar to a transcript? This would fall under 1.2.1, but that's prerecorded audio and video only, also 1.2.2, and even 1.2.3.
given the clarity on this from the BBC guideline, we have this as an advisory technique. How does the user know how the different meta-tags are available – how is this presented to the user? I've just seen links to transcripts with an obvious link title. John mentioned in the survey 1.1.1, could go under that as well.

Potential Solution:
Advisory technique and reference 1.2.1, 1.2.2, 1.2.3, 1.1.1 in reference the time-based media content
|- 
| 41. Avoiding automatic audio (survey #35) || Audio must not play automatically unless the user is made aware this is happening or a pause/stop button is provided ||  PLACEHOLDER || PLACEHOLDER ||
Discussion: This is already a sufficient technique under 1.4.2. We should just make sure that we have a mobile example specifically for this. Anything more specific to mobile? Related to experience with keyboard access to these, the keyboard controls don't often work, but that probably doesn't affect what were going to say here. Yes, we are specifically addressing the requirement under 1.4.2

Potential Solution:
mobile example under 1.4.2
|}