Changes

We should plan to have an 'Accessibility Features' highlight box on our Main page that alerts users to features and options that will assist their use of the wiki.  There we can describe how to take advantage of the new options and preferences that will be provided with new software.  We could prepackage these into specialized skins, and show users how they can customize significant features with skin-specific .css and .js pages for their accounts.

We should plan to have an 'Accessibility Features' highlight box on our Main page that alerts users to features and options that will assist their use of the wiki.  There we can describe how to take advantage of the new options and preferences that will be provided with new software.  We could prepackage these into specialized skins, and show users how they can customize significant features with skin-specific .css and .js pages for their accounts.

This would serve to educate all users about accessibility and provide new capabilities that can advantage usability for everyone, better accommodating the various minorities, without degrading functionality or aesthetics for the majority. --[[User:FGrose|FGrose]]

This would serve to educate all users about accessibility, and better accommodate not only the various minorities, without degrading functionality or aesthetics for the majority, but provide new capabilities that can advantage the usability for all. --[[User:FGrose|FGrose]]

== wiki-devel test design ==

== wiki-devel test design ==

* show on hover only - like the Wikipedia MonoBook and Vector skins, I prefer not to clutter the content area with lots of horizontal lines that interfere with the typeface descenders, make reading the text more difficult, and tire the eyes. --[[User:FGrose|FGrose]]

* show on hover only - like the Wikipedia MonoBook and Vector skins, I prefer not to clutter the content area with lots of horizontal lines that interfere with the typeface descenders, make reading the text more difficult, and tire the eyes. --[[User:FGrose|FGrose]]

*: The bottom-border underscores move them below the descenders (at many resolutions), so this is an improvement in readability.  The excess of horizontal lines in the content text remains an issue, in my opinion. I've found that the excess ink and horizontal lining of solid underlines can be reduced by using a dotted, lightgray bottom-border underline {text-decoration:none;border-bottom:1px dotted;border-color: gray}. (But see also just below.) --[[User:FGrose|FGrose]] ([http://www.mail-archive.com/marketing@lists.sugarlabs.org/msg00968.html discussion post])

*: The bottom-border underscores move them below the descenders (at many resolutions), so this is an improvement in readability.  The excess of horizontal lines in the content text remains an issue, in my opinion. I've found that the excess ink and horizontal lining of solid underlines can be reduced by using a dotted, lightgray bottom-border underline {text-decoration:none;border-bottom:1px dotted;border-color: gray}. (But see also just below.) --[[User:FGrose|FGrose]]

::[http://www.mail-archive.com/marketing@lists.sugarlabs.org/msg00917.html From] Josh Williams, web designer working on the redesign: I'm with you on having the underscores only appear on hover for the main content, but there's a really big usability problem there for color blind people or users with a grayscale monitor. If you go to http://sugarlabs.org on the XO and set the screen to gray scale it's extremely difficult to find links because there's no visual cue other than color.

::[http://www.mail-archive.com/marketing@lists.sugarlabs.org/msg00917.html From] Josh Williams, web designer working on the redesign: I'm with you on having the underscores only appear on hover for the main content, but there's a really big usability problem there for color blind people or users with a grayscale monitor. If you go to http://sugarlabs.org on the XO and set the screen to gray scale it's extremely difficult to find links because there's no visual cue other than color.

* left or right position - I find the left position of these links, just preceding the section title, interferes with the clarity of reading and scanning the titles. I prefer that the [edit] section links be moved to the right like in the MonoBook and new Wikipedia Vector skins.

* left or right position - I find the left position of these links, just preceding the section title, interferes with the clarity of reading and scanning the titles. I prefer that the [edit] section links be moved to the right like in the MonoBook and new Wikipedia Vector skins.

* contrast - I also suggest that they be slightly less dense or grayed from the rest of the text, so that they are easier to ignore when one is concentrating on reading the content on a page.

* contrast - I also suggest that they be slightly less dense or grayed from the rest of the text, so that they are easier to ignore when one is concentrating on reading the content on a page.

* underscores - like the other non-direct content links, if they only show an underscore when hovered with the mouse pointer, we could reduce the amount of unessential 'ink' on the page that distracts, tires the eyes, and changes the graphic feel of the page. For those on monochrome displays, links that are inline with content text are the ones that can't be found. The side bar, table of contents box, editsection, and other links on utility pages are always links—a fixed feature of MediaWiki. These don't need the underline distinction. Arbitrary links like those in content text are the ones that benefit from a distinguishing underscore.  --[[User:FGrose|FGrose]]

* underscores - like the other non-direct content links, if they only show an underscore when hovered with the mouse pointer, we could reduce the amount of unessential 'ink' on the page that distracts, tires the eyes, and changes the graphic feel of the page. For those on monochrome displays, links that are inline with content text are the ones that can't be found. The side bar, table of contents box, editsection, others on utility pages are always links—a fixed feature of MediaWiki—and not arbitrary links like those in content text. These don't need the underline distinction. --[[User:FGrose|FGrose]]

==== Fixed width page or 100% of window ====

==== Fixed width page or 100% of window ====

strings of text. Also I don't enjoy resizing the window just for sites that do this..." and explained some options as well as requested further discussion.

strings of text. Also I don't enjoy resizing the window just for sites that do this..." and explained some options as well as requested further discussion.

: I find that I want to reflow text into wide windows often so I can compare versions and different pages by stacking them above and below each other.  I'm frustrated by sites with fixed width because this prevents reflowing the text into long windows. Because of this, more text is hidden from single view and reducing my effectiveness by forcing me into vertical scrolling and shorter comparisons. (Side-by-side window comparisons are often frustrated by images and other features that float the text into unusual jumbles.)

: I find that I want to reflow text into wide windows often so I can compare versions and different pages by stacking them above and below each other.  I'm frustrated by sites with fixed width because this prevents reflowing the text into long windows. Because of this, more text is hidden from single view and reducing my effectiveness by forcing me into vertical scrolling and shorter comparisons. (Side-by-side window comparisons are often frustrated by images and other features that float the text into unusual jumbles.)

: This seems to be an issue of which configuration provides more capability and freedom to use it, and optimizing convenience without  restricting capability. See [[#Accessibility]]. We could set a default that most prefer and include the capability to set personal preferences. --[[User:FGrose|FGrose]]

: This seems to be an issue of which configuration provides more capability and freedom to use it, and optimizing convenience without  restricting capability. --[[User:FGrose|FGrose]]