DraftStyleSheetIssues

From html4all

Jump to: navigation, search

Contents

Improving the Usability and Accessibility of the CSS used in the HTML5 Editors' Draft

Meta-Issue 1

The offer/attempt to add context using CSS-generated text (for example, using :before and :after to generate content which marks the beginning of a "big issue" and the end of a "big issue") is appreciated, but support for CSS-generated text is extremely spotty to non-existent; most GUI screen readers, which have to scrape the screen (technical term: create an on-screen model) of the page (in effect, take and hold a snapshot of the page as rendered at a particular time in memory) in order to scrape the generated content, so as to expose it to a screen reader or refreshable braille display. Since AT and UA support for CSS-generated content is poor to spotty, research is being conducted to ascertain what works with today's technologies. To this end, I have begun to mount some tests of generated content to gather hard data on support for generated content in screen readers - consult:

to which a simple test document of support for CSS-generated text is attached:

The results of tests of this resource are archived in the following thread:


Meta-Issue 2

Since the style rules defined for .issue and .big-issue are identical, no one (sighted or otherwise) can determine from the styling what is an "issue" and what is a "big issue". Why are the style rules defined for "issue" and "big issue" identical? If they remain so, then the text-strings "Issue: " and "Big Issue: " should be explicitly added to the document as actual, and not pseudo, content, as illustrated below:

  <style type="text/css">
  .issue, .big-issue { color: #E50000; background: white; border: 
  solid red; padding: 0.5em; argin: 1em 0; }
  </style>

  <!-- ... -->

  <p id="issue-alt3" class="issue">
  <strong>Issue:</strong> This paragraph illustrates non-generated labelling text 
  contained within the current style rules for "issue"
  </p>

  <p class="big-issue">
  <strong>Big Issue:</strong> This paragraph illustrates non-generated labelling text 
  contained within the current style rules for the class "big-issue"
  </p>

"element" Style Rule

The inability of screen readers and other assistive technology to detect background and foreground colors using hexadecimal or RGB values has been logged as a bug and/or feature request with several developers of open source assistive technologies (such as Orca and NVDA) and such functionality has been submitted as a "feature request" to major commercial AT developers; currently the capacity to detect font color changes to effect a vocal characteristics change is not supported by any of the screen reader developers or implementors -- however, the lead of the Orca project, Willie Walker, agreed that the capacity to detect changes defined with hex or rgb notation is an eminently implementable feature for a screen reader, and it has been entered into the Orca bug queue

  .element { background: #EEEEFF; color: black; margin: 0 0 1em -1em; 
  padding: 0 1em 0.25em 0.75em; border-left: solid #9999FF 0.25em; }
  .element2 { background: inherit; color: green; margin: 0 0 1em -1em; 
  padding: 0 1em 0.25em 0.75em; border-left: solid #9999FF 0.25em; }
  .element3 { background: inherit; color: navy; margin: 0 0 1em -1em; 
  padding: 0 1em 0.25em 0.75em; border-left: solid #9999FF 0.25em; }
  .element4 { background: inherit; color: purple; margin: 0 0 1em -1em; 
  padding: 0 1em 0.25em 0.75em; border-left: solid #9999FF 0.25em; }
  .element5 { background: inherit; color: olive; margin: 0 0 1em -1em; 
  padding: 0 1em 0.25em 0.75em; border-left: solid #9999FF 0.25em; }

POSSIBLE PROBLEM: Those whom I was able to get to check the following style rule visually, recommended that i make the contrast between foreground and background colors more distinct, which i attempted to do by setting the font-weight to bold; this may still cause contrast issues for a wide range of users and merits further investigation and comment by the Web Content Accessibility Guidelines Working Group

 
  .s2 { border: solid thin; background: silver; color: black; padding: 0.5em; }
  .s3 { border: solid thin; background: silver; color: black; font-weight:bold; 
  padding: 0.5em; }

Font Characteristics for CODE Identical to Those for "Issue" and "Big Issue"

Red is already used as a signifying color; why not use another, namely "maroon"?

  .code2 { color: maroon; background: transparent; } }

CSS-Generated Text: Issues and Options

If one hides the :before and :after content by defining both foreground and background colors as 'transparent' they are not exposed to a screen reader; If visibility:hidden or display:none is used, the content of the :before and :after will be hidden from ALL renderers -- consult:

Moreover, even though FF3/minefield generates the contents of the :before and :after pseudo elements, and writes them to the screen, i have yet to find a screen-reader on the windows platform that includes the contents defined using :before and :after in its aural rendering:

  .example2 { display: block; color: black; background: white; 
  border-left: double; margin-left: 1em; padding-left: 1em; }

  .example2:before { content: "Begin Example: "; display: block; bold; 
  background:transparent; color:transparent; }

  .example2:after { content: "end Example"; display: block; 
  background:transparent; color:transparent;}

  .example3 { display: block; color: inherit; background: inherit; border-left: double; 
  margin-left: 1em; padding-left: 1em; }

  .example3:before { display: block; margin-bottom: 1em; padding: .35em; 
  background: gray; color: white; content: "BEGIN EXAMPLE: "; font-weight: bold; }

  .example3:after { display: block; margin-top: 1em; padding: .35em; background: gray; 
  color: white; content: "END EXAMPLE"; font-weight: bold; text-align: right; }

"Issue" and "Big Issue" Issues

This suggestion is pretty straight-forward - simply adding a :before to indicate that the following block of text is "a big issue". However, generated content is VERY poorly supported by assistive technologies, especially screen readers, so its utility is, at present, limited.

 .issue2, .big-issue2 { color: red; background: white; border: solid red; 
 padding: 0.5em; margin: 1em 0; }

 .issue2:before { content: "Issue: "; font-weight: bold; }

 .big-issue2:before { content: "Big Issue: "; font-weight: bold; }

A second consideration is that since the styles defined for an "issue" and a "big issue" are the same, the differentiation/identification "Issue: " and "Big Issue: " should, therefore, appear in the document source not as pseudo-text, but as actual text strings: otherwise, how is one to differentiate between the two?

  <style type="text/css">
  .issue, .big-issue { color: #E50000; background: white; border: solid red; 
  padding: 0.5em; margin: 1em 0; }

  .issue-label ( font-weight: bold; }
  .big-issue-label { font-weight: bold; }
</style>

<!-- ... -->

  <p id="issue-alt3" class="issue">
  <em class="issue-label">Issue:</em> This paragraph illustrates non-generated 
  labelling text contained within the current style rules for "issue"
  </p>

  <p class="big-issue">
  <strong class="big-issue-label">Big Issue:</strong> This paragraph illustrates 
  non-generated labelling text contained within the current style rules for the class 
  "big-issue"
  </p>

Instead of pseudo-content, why not actual content "hidden" using technique C7 to overflow actual document content so that while it is not rendered to the screen, it is still available to alternate output assistive technologies, as pseudo-elements are not available via the DOM. This would have the added benefit of carrying contextual/explicit markers/indicators available to non-CSS-aware user agents and would make the informative plain text version of W3C drafts much more useful.

Personal tools