- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Tue, 10 May 2016 00:02:07 +0100
- To: w3c-wai-gl@w3.org, "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>
On 09/05/2016 22:10, Sailesh Panchang wrote: > I point out that SC 3.2.2 says, "... unless the user has been advised > of the behavior before using the component". > So often in situations of checkboxes for filters sometimes accompanied > with a sort feature too, if things are happening dynamically in an > 'non-visual' manner, I suggest they need to include a visual > notification advising users of the behavior Per 3.2.2 this should be a notification *prior* to actually doing anything, right? > or placement of a > go-button that triggers the change only on user request. For both, I would say that many sites (certainly search options on shopping sites) regularly *don't* do this, and arguably for good reason - many users want to tick boxes/filters and see immediate dynamic changes happen. It's now mostly expected behavior for many users, and going back to an explicit submit/go button will often not be an acceptable compromise. And even if there was a submit/go button, and a user activates it...if the result is a "silent" dynamic update of search results in another part of the page, but nothing is exposed to the user which may prompt AT to aknowledge that something actually happened, the user will have no idea if what they just activated had any discernible effect, or if there was a JS error, or the site is badly coded and only reacts on mouseup rather than click, or... Also, here I'd argue that on a page with search results and filter options, when just the search results are dynamically updated, arguably it's *not* necessarily a change of context in the sense of point 4 "content that changes the meaning of the Web page." https://www.w3.org/TR/WCAG20/#context-changedef - the meaning is still the same, just the actual results are different. The page didn't transmogrify from being a search page into being something else, like an image gallery or whatever... > I agree, using title / aria-label and aria-live / aria-controls can > be included in the recommendations. > A title attribute helps AT users and mouse users ... user agents > really should be made to support title for keyboard users too. [1] > [1] https://blogs.windows.com/msedgedev/2016/04/20/building-a-more-accessible-web-platform/ (and although you point to an article about plans for Edge to become more accessible, as pointed out in another thread - on WebAIM I believe - IE11 and Edge actually do show title as a tooltip in Win8 and Win10 already...so really, it's all the other browsers that need to catch up :) ) > > Also updating table caption / heading above the newly displayed > content / search / filtered results and judicious use of aria-live > helps. > Depending on situation and context, one can use the present SCs > notably 3.2.2, 1.3.2, 2.4.3 at most times. Depending on the various interpretations of what is and isn't a "change of context", and only for situation where something is a result of either focus or action/activation. So quite a few loopholes and grey areas (changes of content that don't arguably change the "meaning" of a page, or changes that occur not directly as a result of focus/input, such as the originally mentioned flipping from landscape to portrait - unless this is stretched to be a "viewport" change, though originally that didn't really cover this orientation change scenario - or something updated because of a timer, server notification, etc). > For the update to count of items in cart, if it is not in viewport > for anyone or not easily perceivable even by non-PWD, one can > highlighht that as a big usability issue generally and that may be > considered more critical (sadly than even accessibility) by many > clients and get fixed on a priority basis. This will heavily depend on lots of other factors again, such as viewport size, zoom, potential magnification software being used, etc. Many of these can't be tested consistently or detected by authors. And what if the update happens right next to whatever the user clicked, but this fact/notification isn't apparent to non-sighted AT users anyway? At least for this user group, visual proximity is of no relevance. > Clients can be urged to change the UI design and then with aria-live > etc. the content can be made accessible as well. > Defining anew SC can be tricky and create some overlap. Overlap may not be problematic - I'd say there already are quite a few cases of overlap. In fact, if a new more general SC is introduced about the general need to somehow notify/provide a mechanism/make a programmatically determinable thing that tells the user something elsewhere on the same page has changed, then there can be more explicit cross-referencing from those SCs that we've discussed so far, where - depending on interpretation - some argue it's already covered while others don't feel it's actually quite the right fit. P -- Patrick H. Lauke www.splintered.co.uk | https://github.com/patrickhlauke http://flickr.com/photos/redux/ | http://redux.deviantart.com twitter: @patrick_h_lauke | skype: patrick_h_lauke
Received on Monday, 9 May 2016 23:04:46 UTC