Talk:New WCAG 2.0 Techniques

THIS PAGE HAS BEEN KEPT FOR HISTORICAL PURPOSES. The content was re-formatted on the page.

Applies to Mobile Web and Mobile Apps

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). - see http://www.quirksmode.org/blog/archives/2010/04/a_pixel_is_not.html (best practice)
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; what we need in the future is Touch Accessible: Make all functionality available from a touch screen)
Automatically filling in information if known (location into a form field) (best practice)
Define the hover, focus, selected and touch (regular, long) states (see https://hacks.mozilla.org/2013/04/detecting-touch-its-the-why-not-the-how/) Sufficient Technique 2.1.1, 3.2.1 or 3.2.2, UAAG 1.3 - incorrect use could cause failure; needs to be further defined
Touch target size Advisory Technique 2.1.1 - but better as a new guideline; Touch Accessible: Make all functionality available from a touch screen
Spacing requirements (best practice)
Interactive elements should respond on the up touch rather than the down touch -- 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
Use of enhanced contrast (Already a technique WCAG 2.0 1.4.6; think about whether the more strict contrast 4.5:1 applied to all elements)
1. Mobile devices may need higher contrast most of the time
2. Items are smaller may require more contrast (18pt or larger is smaller on mobile)
3. Support for alternative input mechanism on devices that do not have or support a physical keyboard / equivalent access for keyboard

(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 visual/audio indication for all functions

(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.

(Potential solution: duplicate under number 28?)

10. Provide instructions for custom functions and gestures

(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 (best practice)

12. Support the characteristic properties of the platform (e.g. zoom, larger font, captions)

Mobile Web

Limit the number of http calls. (best practice)
Unnecessary JavaScript libraries should not be included in pages by default. (best practice)
Limit source code size (best practice)
All functionality should be available through server-side functions, which can then be enhanced. (best practice)
Width and height attributes should be specified on an IMG tag. (best practice)
Using CSS media queries to turn a multi-column desktop layout into single-column large text view when using zoom magnification
Provide a link to switch between mobile and desktop sites (best practice)
Minimize use of text fields (best practice)
Viewport must allow pinch zoom without assistive technology up to 200% (User-scale/maximum-scale meta) (1.4.4)
Use semantic markup to hide content obscured by flyout menus (SC 1.3.1)
Collapse navigation menus into a descriptive menu button on narrow viewports
Mobile version of the website should provide the user access to the same information and services as the desktop version
Avoid the use frames in web interfaces

General Techniques

These techniques need to be broken down into specific items.

Progressive enhancement techniques should be adopted.
Responsive design techniques should be adopted.

Mobile Apps

Apps respond to accessibility events from the assistive technology such as page change and scroll events.
Apps send events such as layout change events such as when a screen changes from portrait to landscape.
When running screen reader, disable drag events when swipe gestures are required.
When screen readers are activated all screen overlay functions present the top most view/layer/page for reading and the underlaying view/layer/page is not read (IE: Correct view controller techniques are utilized in iOS).