Denise (
denise) wrote in
dw_accessibility2009-11-26 02:16 am
Describing system styles
I've just filed bug 2124 as a medium-term goal to improve the journal customization process for people using screenreaders or people with low or no vision, to provide descriptions of each system style. This way, people with low/no vision will be able to have descriptions of each style read to them, allowing them to choose what they want their journal to look like to sighted visitors.
I'm the first to admit that I don't know what would be useful as opposed to what would be annoying, though, so I toss out the question: what would be useful? What would be annoying?
Text of bug behind cut tag for those who find Bugzilla hard to screenread:
Bug 2124 - Add 'style description' information to all system styles, display in /customize
A few weeks ago, Azz did a code tour that included describing the new system
styles and themes that were added, for the benefit of people who were using
screenreaders and/or who had partial vision but not complete. I've seen a few
people banter about the idea of extending that to a full system-wide thing, and
I really like the idea from an accessibility standpoint:
* Add a new S2 property, method, whatever, for "layout_description"
* Fill in the layout description for all current public styles, two or three
sentences that describe the appearance of the style. Mark did one in irc
tonight that I thought was really good (and made me remember to file this bug):
"Skittlish Dreams is a fairly typical blog layout -- a colored heading at the
top with the blog title and main links. The left side is about 75% of the page
and contains the entries. On the right in the remaining 25% is a sidebar
containing the user icon, calendar, popular tags, page summary box, etc. At
the very bottom of the page is a footer that just says 'powered by
Dreamwidth'."
* Indicate somehow, through a clickable link in the Customize area (like the
preview function for each layout is) or through some trick that makes
screenreaders read out the description when asked somehow, that there are
available descriptions for people who want them. I don't know about the best
practices here -- I'll post to dw_accessibility -- but the idea is to have it
available for screenreader users if they want it, and easy to get, but not read
by default. (Otherwise, reading through that page would be tedious and
annoying.)
Best practice going forward from there would then be to require each new theme
to have a layout description included, on the order of two/three sentences
explaining what it looks like with as value-judgement-free language as
possible, so people with minimal vision will be able to better contemplate what
they want their journals to look like to other people.
I'm the first to admit that I don't know what would be useful as opposed to what would be annoying, though, so I toss out the question: what would be useful? What would be annoying?
Text of bug behind cut tag for those who find Bugzilla hard to screenread:
Bug 2124 - Add 'style description' information to all system styles, display in /customize
A few weeks ago, Azz did a code tour that included describing the new system
styles and themes that were added, for the benefit of people who were using
screenreaders and/or who had partial vision but not complete. I've seen a few
people banter about the idea of extending that to a full system-wide thing, and
I really like the idea from an accessibility standpoint:
* Add a new S2 property, method, whatever, for "layout_description"
* Fill in the layout description for all current public styles, two or three
sentences that describe the appearance of the style. Mark did one in irc
tonight that I thought was really good (and made me remember to file this bug):
"Skittlish Dreams is a fairly typical blog layout -- a colored heading at the
top with the blog title and main links. The left side is about 75% of the page
and contains the entries. On the right in the remaining 25% is a sidebar
containing the user icon, calendar, popular tags, page summary box, etc. At
the very bottom of the page is a footer that just says 'powered by
Dreamwidth'."
* Indicate somehow, through a clickable link in the Customize area (like the
preview function for each layout is) or through some trick that makes
screenreaders read out the description when asked somehow, that there are
available descriptions for people who want them. I don't know about the best
practices here -- I'll post to dw_accessibility -- but the idea is to have it
available for screenreader users if they want it, and easy to get, but not read
by default. (Otherwise, reading through that page would be tedious and
annoying.)
Best practice going forward from there would then be to require each new theme
to have a layout description included, on the order of two/three sentences
explaining what it looks like with as value-judgement-free language as
possible, so people with minimal vision will be able to better contemplate what
they want their journals to look like to other people.

no subject
no subject
no subject
I like Mark's description in a general sense. I think you're correct to say value-free language, but at the same time I think some more loaded description might be important since layouts can -- I gather -- really have a . . . feel? mood? to them. Which is often explained in the theme name, but having words like "clean/elegant/quirky/haphazard/whatever" would be kind of nice, because that's really what I'm after as much as how much of the page is the sidebar.
Also, and I think this has been under discussion before, it might be nice to mark a handful of layouts as particularly useful for x access issues. E.g., "this layout is one of the higher-contrast visually." The trick here being to do this without accidentally ghettoizing.
no subject
And we already have separate plans to mark visual contrast level (high, average, low) for all themes so don't worry about that.
no subject
no subject
no subject
Also I agree with
no subject
This sort of verbal description is going to be something I find really, really hard to do, even with clearer guidelines/a describing template, but at this point, based on Mark's description and the description that was posted in dw-suggestions, I can not produce a verbal description because I have no idea what the description should say. Can we separate the "make a theme" and "describe a theme" functions, the way "make a theme" and "make a style preview" are separated? If not, can we get some sort of fill-in-the blank template on what your theme description should say?
Also, should the theme descriptions repeat the layout descriptions, or are those going to be separate?