This is the user sandbox of GJR. A user sandbox is a subpage of the user's user page. It serves as a testing spot and page development space for the user and is not an encyclopedia article. Create or edit your own sandbox here.

Other sandboxes: Main sandbox | Template sandbox

Finished writing a draft article? Are you ready to request review of it by an experienced editor for possible inclusion in Wikipedia? Submit your draft for review!

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...
1. consider the obvious problem posed to
  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 list-item-style 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);
this is a clear, obvious and inexcusable violation of the Wikipedia Manual of Style by those who construct and vet the templates for Wikipedia:
1. Color (Manual of Style)
2. Images (Manual of Style)
3. Wikipedia:ALT
  )

WCAG 2.0 Reference on `list-style-image`

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:

background,

background-image,

content, combined with the :before and :after pseudo-elements,

list-style-image

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 FORM control when a screen reader enters "forms mode" (a special overlay that allows the user to interact exclusively with form controls)

Solution

add role="button" to the code defining the "Cancel" hyperlink
<a href="/wiki/User:username/sandbox" title="User:username/sandbox" role="button" id="mw-editform-cancel">Cancel</a>
this will cause the user's assistive technology to process the javascripted hyperlink that replaces the standard FORM control as if it were an actual form control encoded as an actual "Cancel" button (<input type="cancel">)
add CSS styling to the "Cancel" hyperlink so that it is identical to the actual FORM controls to reinforce the fact that it functions as a "Cancel" button -- a feature of forms most usually presented using an actual FORM control (<input type="cancel">)
encase the entire form (including "standard" FORM controls and javascripted form controls, such as the "Cancel" hyperlink) in a role="form"

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 `role="form"`

the Mediawiki "Edit" form mixes HTML FORM 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 FORM control, but a javascripted link which performs a common and necessary FORM function -- the cancellation of an edit attempt -- which the vast majority of users expect to be an actual FORM control...