User:GJR/sandbox

= watchlist "green bullet" (page updated since last visit) feature inaccessible =

the following appears in the second paragraph of the introductory text for the Wikipedia Watchlist, immediately preceding the "Mark all pages as visited" button in the document's reading-order:"Pages that have been changed since you last visited them are shown with a green bullet."

problems:  this information is conveyed using a purely visual indicator;  due to the use of CSS to insert the green bullet into the page's visual rendering, there is no "alt" text (of any kind) available for those who cannot process images... this means that there is no programatic binding between the iconic "green bullet" and a textual equivalent for the icon which would enable a blind user's screen reader to say (for example) "changed", whenever the screen reader encounters the code that causes the bullet icon to be visually rendered, thereby making the visual indicator accessible to those who cannot perceive it;  the choice of a color as the sole means of communicating essental information to the user; reliance on a color change to a universally recognized page element (a bullet) rather than the provision of a distinctive icon (or other symbolic convention) to convey the intended information -- that the page's content has been updated since the user's last visit -- to the watchlist user...  consider the obvious problem posed to color blind users; a.k.a. users with a "color vision deficiency" to use the current medical/scientific term for the range of conditions traditionally labelled "color-blindness"... the "greeness" of the bullet will not be perceptible to users with monochromacy (also known as "total color blindness"), achromatopsia and red-green color-blindness... additionally, users with tritanopia and tritanomaly experience great difficulty discriminating between blue and green hues and may not, therefore, perceive the "green bullet" as "green" -- a situation exacerbated by the fact that the default  for unordered lists in Wikipedia causes the rendering/generation of blue bullets  this is a clear, obvious and inexcusable violation of the W3C's Web Content Accessibility Guidelines and Authoring Tools Accessibility Guidelines (ATAG); <li>this is a clear, obvious and inexcusable violation of the Wikipedia Manual of Style by those who construct and vet the templates for Wikipedia: <ol style="list-style-type:upper-latin"> <li>Color (Manual of Style)</li> <li>Images (Manual of Style)</li> <li>Alternative_text_for_images (a.k.a. ALT)</li> </ol></li> </ol>

WCAG 2.0 Reference on
WCAG 2.0 CSS Technique C9: Using CSS to include decorative images, with special emphasis on the following quote's use of the terms "purely decorative images" and its final cautionary sentence:

The objective of this technique is to provide a mechanism to add purely decorative images and images used for visual formatting to Web content without requiring additional markup within the content. This makes it possible for assistive technologies to ignore the non-text content. Some user agents can ignore or turn off CSS at the user's request, so that background images included with CSS simply "disappear" and do not interfere with display settings such as enlarged fonts or high contrast settings.

Background images can be included with the following CSS properties:
 * , combined with the  and   pseudo-elements,
 * , combined with the  and   pseudo-elements,
 * , combined with the  and   pseudo-elements,

Note: This technique is not appropriate for any image that conveys information or provides functionality, or for any image primarily intended to create a specific sensory experience.

= "Cancel" link on "Edit" form should be marked with ARIA to indicate it functions as a button =

the Mediawiki "Edit" form uses "standard" form controls for all terminal actions except for the "Cancel" mechanism... the "Cancel" mechanism is currently coded as a hyperlink and not as a button, which means that the "Cancel" mechanism is 'not included in a screen-reader generated "list of form controls", where a screen reader user expects to find all of the controls associated with a form, nor is it reported as a  control when a screen reader enters "forms mode" (a special overlay that allows the user to interact exclusively with form controls)

Solution
<ol> <li>add  to the code defining the "Cancel" hyperlink"" this will cause the user's assistive technology to process the javascripted hyperlink that replaces the standard  control as if it were an actual form control encoded as an actual "Cancel" button </li> <li>add CSS styling to the "Cancel" hyperlink so that it is identical to the actual  controls to reinforce the fact that it functions as a "Cancel" button -- a feature of forms most usually presented using an actual   control </li> <li>encase the entire form (including "standard"  controls and javascripted form controls, such as the "Cancel" hyperlink) in a  </li> </ol>

full disclosure: the ARIA "form" element was orignally proposed within the Web Accessibility Initiative (WAI) by me in reaction to the Mediawiki "Edit" form

= Mediawiki "Edit" form should be marked with ARIA's  =

the Mediawiki "Edit" form mixes HTML  elements with javascripted custom controls which are cannot be recognized as form controls, and consequently are not included in an assistive technology's "list of form controls" and may be excluded from the navigational flow/order experienced by a user of assistive technology which uses a special "forms mode" overlay to enable disabled users to efficiently, expeditiously and confidently use such a hybrid form...  most problematic of the hybrid controls is the form's "Cancel" mechanism, which is not a   control, but a javascripted link which performs a common and necessary   function -- the cancellation of an edit attempt -- which the vast majority of users expect to be an actual   control...

full disclosure: the ARIA "form" element was orignally proposed within the Web Accessibility Initiative (WAI) by me in reaction to the Mediawiki "Edit" form