ABCDEFGHIJKLMNOPQRSTUVWXYZAAAB
1
Folder:https://drive.google.com/drive/folders/1Q9md2AvmeTgvsT9GB62BsGvCaalDGtE6?usp=sharing
2
What's neededWhyWhere previously discussedInitial ProposalNotesDraft ProposalExamplesSC Proposal / Assigned toLVTF thoughts http://w3c.github.io/low-vision-a11y-tf/user-needs-coverage.htmlComment
3
2.2?Proper nesting of roles so UA/AT doesn't get confusedhttps://github.com/w3c/wcag/issues/770#issuecomment-499543402JakeClose to Success Criterion 4.1.1 ParsingIn content implemented using markup languages, roles are nested according to their specifications.
4
2.2Spacing between touch targets - set a minimum number of pixels between targetsKathy Wahlbinsome users need larger targets; hover over then can break the design astetics; consider exempt text but then may have challenge for menusIf the target for pointer inputs is less than 44 by 44 CSS pixels then there is a minmum of 8 CSS pixels between targets except when:
Equivalent
The target is available through an equivalent link or control on the same page that is at least 44 by 44 CSS pixels;
Inline
The target is in a sentence or block of text;
Essential
A particular presentation of the target is essential to the information being conveyed.
(Level AA)		Kathy to draft SC

https://docs.google.com/document/d/1sszSUKB8t3VuRzxHtOjLfQZjNYCw-xr_EbuMwW7WiGc/edit#

Initial Draft created		need a low vision use case. if holding device close finger gets in the way moreQuestions for low vision group: How many pixels in between meets user need on the low-vision side? We have it at two pixels. And does the overall target size impact the spacing requirements?

0.4em is non-breaking space; 8 pixels with no styling -- do we need an exception for non-styled button

Kathy, I took this up as SC development lead in one of the recent AG telcos but I'd be happy to pass that on to you since you are down for it here anyway :)
5
2.2Different content when portrait / landscape so user can miss out on content , this is not about same content adjusted by reflow (TPAC discussion)Jakenot covered under the existing SC under 2.1; portrait and landscape are two separate views but are only available in one view or the other; all functions are available in portrait and landscrape; also cognitive part to this as well.

https://m.nl.investing.com/commodities/crude-oil-advanced-chart

https://www.w3.org/WAI/WCAG21/Understanding/orientation.html

Intent

Some websites and applications automatically set --- and --- +++ or +++ restrict the screen to a particular display orientation and expect that users will respond by rotating their device to match

Therefore, websites and applications need to support both orientations ---by not restricting the orientation. --- +++ by not offering functionality only in one orientation +++

Changes in content or functionality due to the size of display are not covered by this criteria which is focused on restrictions of orientation. +++ this sentence hints at reflow, and while this is also a fail for the example given, the size of display is not change when page is used on tablet or phone, only the orientation, and still offers other functionality +++		All functionality must be available in both landscape and portrait display orientations.
(Level A)		Next Step: get examples of adaptive layout issues to illustrate this -- JAKELV users then turn to landscape to make content and controls bigger. also, onscreen keyboard is bigger.... more lines on the page.e.g. if a five-year stock outlook is available in landscape mode, it must be available in portrait mode as well.

Can this be tested? What is the width of landscape and portrait mode?

This will capture the issues with adaptive layouts (reflow is for responsive?)

Content can be presented without loss of information or functionality in landscape and portrait display orientations.
6
2.2Indication of gestures with e.g. icons, touch and/or device movementsJake2.5.4 Motion Actuation => related, but also gesture based here
3.3.2: Labels or Instructions => doesn't fit = input based
3.3.5 Help => pretty close, but AAA

Consider adding a technique under 3.3.5 for gestures (contextual help)		When (hidden) functionality is available via gestures or movement, the user is informed of / instructions are available for, the method on how to use them, can be turned off, and can also be operated by user interface components via alternative ways.

(Level AAA) or Technique		JAKE to draft SCrelated to LV visual affordanceDetlev:
Arguably 2.5.1 pointer gestures and 2.5.4 Motion Actuation make that less urgent as a single pointer operable control with meaningful accName needs to be present anyway to conform.
Would information need differentiation by mode of use (e.g. when default action is to swipe left to open drawer, this will be different when turning on screen reader it may not work, or engage two fingers - or is this a non-issue?)

Questions for low vision group: can we group this together with what you are working on with visual affordance – how should we work together on this?
From 2019-02-01 email
From a desktop scenario many people with low vision may have difficult time finding and precisely using the mouse pointer. Because of this -- a significant number use the keyboard for navigation when possible. Many of us use the mouse out of necessity because keyboard interacting is not effective either because of limited support for moving between sections of a page and because of poor visual indication of focus issues on web pages.

Anyway – because low vision users use the keyboard more often for navigating we lose the ability to get that hover feedback about actionable elements. So often I find myself tabbing through the page just to find if there is a clickable element to see what is available. Having better affordances would allow us to know what is clickable visually without having to move the mouse or the keyboard. I often don’t know what on a page is interactive and when you are zoomed in your get a limited view of the page – so navigating with the keyboard to try and figure out what is interactive can wildly change the view from where you were on the page.

Jonathan
7
Technique under 2.4.3 - 2.4.7Focussed elements disappearing under sticky headers/footersJakefocusable items must be visible on the screen; failure or sufficient technique for focus indicatorsTechniqueMark?content that is focused should be fully visible.

Can this be combined with the focus management SC 2.4 3?
8
Technique under 2.4.3Focus management when zooming / rotating / deleting elementsJakefocus on a menu items then zoom in then in hamburger management; check with low vision taskforceTechniqueMark?related to LV page refresh. context (full page) vs non-context (part of page) refresh. what is best practice for each scenario. Need user stories.Technique under 2.4.3 A?
When focused content is collapsed or deleted, the focus is reset to a related component, e.g. the focus is on a menu item; when the menu collapses to a hamburger menu due to zooming, the focus is reset to the hamburger menu item
9
2.2States discernableImportant issue for LV and COGA users, but may be seen to fall more under usabilityI have put a draft here to get some feedback beyond our group, becasue it is not primarily a mobile issue: https://github.com/w3c/wcag/issues/559Detlev12. Dec 2018:
A general affordances SC (the last point in the LVTF list of SCs for Silver presented in this week's call) seems very hard to pin down - answering a question like "What should an interactive user interface component look like to convey the appropriate affordance?" is likely to be very contentious. So I thought narrowing it down to states might be easier - if a user interface component has different states like on/off, these should be visually discernable. I hope it makes sense to enumerate ways to do that, the problem is that this list may not be exhaustive (and difficult to ever make exhaustive).
I hope this doesn't overlap with things that may be proposed by LVTF or COGA TF, if it does I happily contribute to proposals by those groups, if that is welcome.		Best practice or Level AAA - user interface components must be distinquishable/disernable from other contentDetlev - check if state disternable is covered under WCAG 2.1An example, text that is a link or button but has no visual indicator that it is actionable

Question: is this more of a usability issue than accessibility?

Regroup with low vision and COGA taskforces for futher discussion

Jake suggested to maybe look at consistency

IBM has some patterns defined in their Carbon framework: https://next.carbondesignsystem.com/patterns/common-actions I'm still looking for additional guidance on the Design Language site, but it seems to be all spread out.
10
SilverProvide clear indication that elements are actionablehttps://www.w3.org/TR/mobile-accessibility-mapping/ 4.5Kathy WahlbinShould have further discussion; standard or consistency could be an exemption; maybe a consistent indication of actionable elements (do not mix them) per site/app; don't make text content look the same as the style used for actionable elements

Talk to Low Vision Taskforce - already being talked about in LV for Silver
11
?Open modal own url, badhttps://github.com/w3c/wcag/issues/170#issuecomment-437109868JakeMore discussion.Detlev:
Compare my prüosed answer to (pseudo)-windows opening on page load and the link to SC3.2.1 On Focus here:

https://lists.w3.org/Archives/Public/w3c-wai-gl/2019JanMar/0070.html
12
SilverTarget size for mobile/tablet screen size - targets must not be smaller than XCurrently only at AAAhttps://www.w3.org/TR/mobile-accessibility-mapping/ 3.2Kathy WahlbinLinks in paragraphs are challenging - with responsive and reflow; candidate for Silver but may be able to do a AA for 2.2; clashing requirements - some users want more on the screen;
13
SilverConcurrent Mechanisms 2.1Currently only at AAA because you can't test all combinationshttps://www.w3.org/TR/WCAG21/#concurrent-input-mechanismsKim PatchPeople use different inputs and different combinations of inputs for many different reasons including accessibility. The input methods don’t have to be aware of each other or coordinate, they just both have to work same as they do without the other input method present. It's true that it’s difficult to test all combinations – this also means it's difficult to anticipate what people will need in real situations. There’s a chicken and egg problem here for users. If there’s a combination you can’t do you can’t try it out to see if It’s useful. Maybe it’s enough to test that every input always works even when other inputs are present.

- may be a problem with the different ways actionable items work across different mechanisms (e.g. mouse focus being different than keyboard focus)
14
SilverMotion Actuation 2.1Currently level A but is restricted to motion, no other device sensors are coveredhttps://www.w3.org/TR/WCAG21/#motion-actuationKim Patchaugmented reality that we may want to look at for silver
15
SilverSomething to keep in mind with speech: voice fatigue, brain fatigue, micro interruptions, dovetail with coga, may be something around thisKimneed to keep these in mind for speech; this is different than most typing and interaction; users can have cheat sheets, and as commands become known then less of issue. Micro interuptions - need to watch when teh computer gets it wrong, it is a different user experience; users cannot relax. On mobile, this is now an issue to as more users are using speech. Letting users save and share settings may help.
16
SilverLet users save and share settings (save lots of time, lets people help themselves and others)Kimmay be a AAA requirement or Silver. This would save time for trainers, allow users to have multiple settings, make setting up a computer not such a time-consuming task etc. speech example is Gmail keyboard shortcuts, but there're examples across user groups. Also relevant to memory
17
SilverLet users save settings they have just changed to review and keep oriented (back button everywhere) – increasingly important with different screen sizes and an increasing number of apps because the views look different so there's more to remember
KimBrowser specific. This is related to the 2.2 COGA SC on not relying on users having to memorize information.
18
Silver?Gap between label and element labelled (more an issue for the LVTF, and to be discussed with them)Important issue for LV usersDetlevhttps://accessuse.eu/en/drop-down-menus.html/#existenzgruender
Difficult to pin down for pass / fail testing, so maybe Silver - in testing I had a a few cases where LV users could not make the connection between a control and its label - see, for example https://accessuse.eu/en/drop-down-menus.html/#existenzgruender
Likely positive Techniques would be "keep label adjacent to control" "Use rulers or shading to facilitate making a connection between control and label")		Label gaps
When one element acts as a label of another element, the gap between the two is no larger than twice the width or height of the element labelled (whichever is smaller).
I.e., the simple formula is MIN(e.width;e.height)*2

This may be measured with an online ruler, possibly also automatically by a script processing the absolute positions and dimensions of two elements to work out the pixel offset.		Detlev (unless someone from LVTF is already working on it)
19
TechniqueLook at the techniques under the extension for existing WCAG 2.0 success criteriahttps://w3c.github.io/Mobile-A11y-Extension/Kathy Wahlbin
20
2.2 / TechniqueGrouping of contentJakeLook up to see if it is a technique for keyboard => Not present

Jake - may be missing; consider adding as new SC
21
TechniqueInstructions 'custom' components / widgets (name, role, state...)

carousels / accordions etc. don't have existing roles in specs, buttons / slides etc., don't cover their working. roledescription may vary...		Jaketechnique to look at for labels and instructions

sections or UI controls like carousels are not defined or labeled as to what it is -- could be under 4.1.2? => No, UIC is stand alone, looking for "widget clearness" here... atomic Vs. Composed widgets...
22
2.2 / Silver?If you provide biometrics, you should provide something alternative as well – apps that use authenticationshadimay be already covered under 1.1.1; but this is not author driven - this is driven by inputIf biometrics are used, an alternative is provided.usually built into the OS (face recognition), finger print, voice recognition
Look for implementation examples; move to Silver if no examples
23
2.2 / Silver?Custom gestures not preserving default / breaking touchMainly a native app issues but may be a web issue with signaturesJakecustom gestures - signle point and breaking touch; look up conversations around this from minutes; Question: how much power do developers have to override?Custom gestures will not interfere with default AT or OS gestures, e.g. custom two-finger swipe down gesture does not interfere with default voiceover commands on mobile phonewho should manage the conflict- the app or the user+OS+ATAndroid
- Example with Talkback where possible to directly pass gesture to OS with two fingers for signature area. Keyboard user + Talkback (or ball mouse) are not able to use swipe gestures and/or scrolling up down (only swipe) + custom swipe gesture.
iOS
- accessibility trait + signature area in iOS you can use "allows direct interaction trait" (pass through trait / pass through trap!) this trait can wrongly be used for volume controls where a direct pass seems a logical solution if you don't get the volume button to work.
- controls have capability of disabling voice over (ignore voice over gestures), don't capture gestures if not have to and if you do, max half screen for Voice Over. Otherwise you might get 'stuck' on a screen.
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100