User:GJR/sandbox/a11y

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

Note: this report refers to items contained in div class=mw-changeslist in the rendered document source for the Wikipedia Watchlist page.

the following prose 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.

this is a clear, obvious and inexcusable violation of the W3C's Web Content Accessibility Guidelines and Authoring Tools Accessibility Guidelines (ATAG), as well as a clear, obvious and inexcusable violation of the Wikipedia Manual of Style by those who construct and vet the templates for Wikipedia... for details, please consult both the enumeration and explanation of specific problems contained in the next section, as well as:

• Color (Manual of Style)
• Images (Manual of Style)
• Wikipedia:Alternative_text_for_images (a.k.a. Wikipedia:ALT)

problems posed by the use of the green button "feature"

1. this information is conveyed using a purely visual indicator;
1. 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;
2. 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 a unique symbolic convention -- for which a programmatically determinable textual alternative can be defined -- to indicate to the watchlist's user that the page's content has been updated since the user's last visit...
   1. 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 "greenness" 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 list-item-style for unordered lists in Wikipedia causes the rendering/generation of blue bullets
3. there is no non-visually-dependent alternative mechanism to indicate changes to listed pages
   1. a universally accessible and useable indicator should be used to implement this feature; it should not rely on color alone to indicate the status of a watchlisted page...
   2. an image should not be used to convey information to users unless it can be programmatically bound to a textual equivalent for that image/icon/page element such as alt text or the ARIA property aria-label (or aria-labelledby, if an appropriate and unambiguous textual label which can be re-used to provide a textual equivalent for the image appears as text elsewhere in the document)... none of these solutions can be applied to graphics inserted into a document to provide a textual equivalent for images generated via list-style-image)

this "feature" needs to be re-engineered and replaced, either through the scripted -- rather than a CSS-generated -- insertion of an image into the document source to indicate that the listed item has changed since the user's last visit using the IMG/alt tandem, in order to provide a programmatic binding between the image and its textual equivalent, or by another non-modality-specific mechanism, such as the scripted insertion of a terse phrase, such as "changed"... note that the CSS content property, in conjunction with the CSS :before pseudo-element, cannot be used to insert a textual status update, as support for CSS-generated text varies greatly from browser to browser and browser version to browser version, and support for CSS-generated/inserted text by assistive technology (such as a screen-reader or refreshable braille display) is extremely poor, and therefore cannot be implemented as an accessible solution

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

1. 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">)
2. 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">)
3. 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...

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

change modality-specific instructions in bugzilla.wikimedia.org's Advanced Search interface (query.cgi)

summary: not everyone can "hover [their] mouse" to obtain help for field labels

bugzilla's query.cgi contains the advice/tip:

Hover your mouse over each field label to get help for that field.

this is modality-specific advice of no use to those, such as myself, who cannot use a mouse -- i am blind and use a screen-reader and keyboard input only...

since a hover/mouse-over action is NOT the only -- nor the exclusive -- means of obtaining help for each field, the advice text should be changed to read as follows, or -- at least -- should contain all the information included in the following proposed text:

To get help for any field, either hover your mouse over each field label or activate the field label's hypertext. Note: Activating a field label as a link to obtain help for that field will result in the display of the help text for that field as part of a separate wikimedia document. Users who cannot use a pointing device to expose the help text may wish to invoke the help text by opening it in a new browser tab or new browser instance/window, so that both the form and the help file are available to the user.

it is essential that the document inform the user how to access help for the form fields when a hover is not possible, without causing major disruption for anyone attempting to obtain the help text using the hyperlink associated with the field's legend/label. Users need to know how to obtain "interactive" help, and it is crucial that obtaining help not force a user to navigate away from the form in order to review the help text to which the hyperlink points. without such a warning/information, a user who cannot perform a hover action will find that following label hyperlinks to obtain help for a specific field causes the form to be replaced with a help document, thereby not only vastly increasing the cognative overhead necesary to efficiently use the Advanced Search features of bugzilla, but will also result in the resetting of the form to its defaults, thereby erradicating any modifications the user made to the form before invoking help for a specific field when the user returns to the form after obtaining assistance from the associated help text.