- From: Sailesh Panchang <sailesh.panchang@deque.com>
- Date: Thu, 12 May 2016 16:27:30 -0400
- To: Adam Solomon <adam.solomon2@gmail.com>
- Cc: GLWAI Guidelines WG org <w3c-wai-gl@w3.org>, alands289@gmail.com, David MacDonald <david100@sympatico.ca>, Gregg Vanderheiden <gregg@raisingthefloor.org>, "Patrick H. Lauke" <redux@splintered.co.uk>
Once a page is loaded, any new content auto updated or triggered by user action should grab user's attention visually unless the new content is designed and meant to be inconspicuous. If it does not do so for most users generally, it is simply poor usability, and then, poor accessibility too. This may certainly involve fixing the design. As noted in an earlier email this needs to be assessed separately for platforms and class of device / screen sizes. If it is not a matter of poor usability, i.e. the newly displayed content becomes apparent when added, then it is a matter of ensuring it is rendered in an accessible manner. ensuring compliance with SC 1.3.1, conveying change in state (4.1.2), updating text equivalends (1.1.1), also that newly added content meets 1.3.1, 2.4.3 and SC 2.2.1 (read with 3.2.1 as noted by the SC) and of course 3.2.1 / 3.2.2 are sufficient to cover all types of content changes listed as examples / being discussed IMO. Thanks and regards, Sailesh On 5/12/16, Adam Solomon <adam.solomon2@gmail.com> wrote: > buttons (not just links) by definition (if labeled correctly) notify the > user of the change which occurs (i.e. h84) and, therefore, generally > speaking no additional notification needs to be added to fulfill 3.2.2. > Live regions are definitely not required for they did not exist at wcag 2 > writing. > At most, focus would need to be transferred to the new location when > relevant (such as modal content), and when not it is sufficient that > dynamic content is inserted after the users position (per scr26). > An example might be a search bar with a button that when pressed updated > grid results with dynamic ajax content (no postback). Live regions are > great here but not required. Enough that the button indicates that the grid > is affected by the search button (input=button for instance by way of its > value) and the grid is positioned after the search bar. > > > On Thu, May 12, 2016 at 8:33 PM, Sailesh Panchang < > sailesh.panchang@deque.com> wrote: > >> David, >> Programmatic notification: Not needed IMO. >> Error messages too are notifications and a change in content. SC 3.3.1 >> only requires they are described and are in text. Then, if the >> messages indicate relationship via presentation, SC 1.3.1 kicks in. >> This will apply to all similar changes in content. >> BTW, consider a carousel: are we limited by the current set of SCs >> while evaluating accessibility? >> Thanks, >> Sailesh >> >> >> On 5/12/16, David MacDonald <david100@sympatico.ca> wrote: >> > oops "already covered in 4.1.1 " I meant 4.1.2 >> > >> > Cheers, >> > David MacDonald >> > >> > >> > >> > *Can**Adapt* *Solutions Inc.* >> > Tel: 613.235.4902 >> > >> > LinkedIn >> > <http://www.linkedin.com/in/davidmacdonald100> >> > >> > twitter.com/davidmacd >> > >> > GitHub <https://github.com/DavidMacDonald> >> > >> > www.Can-Adapt.com <http://www.can-adapt.com/> >> > >> > >> > >> > * Adapting the web to all users* >> > * Including those with disabilities* >> > >> > If you are not the intended recipient, please review our privacy policy >> > <http://www.davidmacd.com/disclaimer.html> >> > >> > On Thu, May 12, 2016 at 9:42 AM, David MacDonald >> > <david100@sympatico.ca> >> > wrote: >> > >> >> >> >> >> >> >Every time you click a link you change content >> >> I'm not sure what this refers to... if it means the changed state from >> >> unvisited to visited then that's already covered in 4.1.1 and is >> >> accessibility supported, screen readers announce that state. If it >> refers >> >> to taking the user somewhere, then that is a change of *location* not >> >> a >> >> change of content. >> >> >> >> >Every time you click on a pull down menu >> >> Again this is a change of state, from expanded=false to true, and that >> is >> >> announced to the user if it is coded properly, and 4.1.2 requires it >> >> be >> >> coded properly to announce that state, and this is sufficient >> >> notification >> >> "navigation region expanded" >> >> >> >> >When you push down a button and it changes color before you lift it >> >> > up >> >> the mouse? >> >> Again this is a change of state, and it already is required in 4.1.2 >> >> >> >> There are questions to resolve with this SC but I *don't* think >> >> *these* >> >> are of concern. >> >> >> >> Updating content is a significant problem on the modern web. One >> >> issue >> >> to >> >> solve is to decide on the requirements for changes that happen >> downstream >> >> from the control that changes them. We may want to scope out changes >> to >> >> "flow content" when follows the button. >> >> >> >> Cheers, >> >> David MacDonald >> >> >> >> >> >> >> >> *Can**Adapt* *Solutions Inc.* >> >> Tel: 613.235.4902 >> >> >> >> LinkedIn >> >> <http://www.linkedin.com/in/davidmacdonald100> >> >> >> >> twitter.com/davidmacd >> >> >> >> GitHub <https://github.com/DavidMacDonald> >> >> >> >> www.Can-Adapt.com <http://www.can-adapt.com/> >> >> >> >> >> >> >> >> * Adapting the web to all users* >> >> * Including those with disabilities* >> >> >> >> If you are not the intended recipient, please review our privacy >> >> policy >> >> <http://www.davidmacd.com/disclaimer.html> >> >> >> >> On Wed, May 11, 2016 at 7:24 PM, Gregg Vanderheiden < >> >> gregg@raisingthefloor.org> wrote: >> >> >> >>> There are a million things that change content. >> >>> >> >>> Little bitty changes. >> >>> Every time you click a link you change content >> >>> Every time you click on a pull down menu >> >>> When you push down a button and it changes color before you lift it >> >>> up >> >>> the mouse? >> >>> >> >>> I think there may be a world of unintended consequence to introducing >> >>> something that requires warning with every change of content. >> >>> >> >>> Two questions. >> >>> >> >>> 1. what are the problems that real people are experiencing with >> >>> real >> >>> content that blocks them from using it >> >>> 2. have you thoroughly catalogued all the places where content >> >>> changes for any reason - any amount >> >>> >> >>> >> >>> I think you will need to research and thoroughly document both before >> >>> you >> >>> can >> >>> a) determine if the benefit outweighs the problems. >> >>> b) figure out if and how to word an SC that avoids the problems and >> >>> is >> >>> still testable (e.g. you can’t say “significant change in content” >> >>> — >> >>> since an author would never know what an evaluator would consider >> >>> significant. >> >>> >> >>> >> >>> *gregg* >> >>> >> >>> On May 11, 2016, at 5:39 PM, David MacDonald <david100@sympatico.ca> >> >>> wrote: >> >>> >> >>> I've taken stab at tweaking the SC proposal to address Gregg's >> >>> concern >> >>> about "User awareness". I borrowed the language from Programatically >> >>> Determined, and created a new glossary item called "Programmatic >> >>> notification". >> >>> >> >>> SC x.x.x Change of content: Programmatic notification is provided for >> >>> changes in content that either conveys information or indicates an >> >>> action >> >>> was taken, whether these changes are made by auto updates or as a >> result >> >>> of >> >>> user action. (Level AA) >> >>> >> >>> Definition of "Programmatic notification": Notification by software >> from >> >>> data provided in a user-agent-supported manner such that the user >> agents >> >>> can extract and present this notification to users in different >> >>> modalities, >> >>> without futher action by the user, beyond activating the control >> >>> which >> >>> caused the change. >> >>> >> >>> I've updated the Understanding to add Sailesh's examples when this >> >>> applies and his distinction between notification of content... and >> >>> changes >> >>> that can be conveyed by notification of change of states, properties >> and >> >>> values required in 4.1.2. >> >>> The proposal is here: >> >>> >> >>> >> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_SC_on_information_added_or_removed_from_a_page#Proposed_3.4.1 >> >>> >> >>> Cheers, >> >>> David MacDonald >> >>> >> >>> >> >>> *Can**Adapt* *Solutions Inc.* >> >>> Tel: 613.235.4902 >> >>> LinkedIn >> >>> <http://www.linkedin.com/in/davidmacdonald100> >> >>> twitter.com/davidmacd >> >>> GitHub <https://github.com/DavidMacDonald> >> >>> www.Can-Adapt.com <http://www.can-adapt.com/> >> >>> >> >>> >> >>> * Adapting the web to all users* >> >>> * Including those with disabilities* >> >>> >> >>> If you are not the intended recipient, please review our privacy >> >>> policy >> >>> <http://www.davidmacd.com/disclaimer.html> >> >>> >> >>> On Wed, May 11, 2016 at 4:41 PM, Patrick H. Lauke >> >>> <redux@splintered.co.uk >> >>> > wrote: >> >>> >> >>>> On 11/05/2016 21:33, Sailesh Panchang wrote: >> >>>> >> >>>>> "User awareness" is used in the same manner as is used in the >> >>>>> glossary explaining "change of context". Any other alternative >> >>>>> wording? >> >>>>> The SC will need a note to clarify that this does not apply to >> >>>>> links >> >>>>> and such listed in the exclusions listed in that email. >> >>>>> >> >>>> >> >>>> Ditto for "regular" forms, whose submit action would reload the >> current >> >>>> page / load another page. >> >>>> >> >>>> Would the exclusion be, in very broad strokes, along the lines of >> >>>> "unless the change in content as a result of user action is expected >> >>>> and >> >>>> follows standard behavior (e.g. activation of a link resulting in a >> new >> >>>> webpage being loaded)" or similar? >> >>>> >> >>>> >> >>>> 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 Thursday, 12 May 2016 20:27:59 UTC