Dynamically Changing Style Sheers

Thanks Richard,

I am working on different colour backgrounds for stylesheets to do with
colour blindness, not there yet, maybe your girlfriend will be able to
easier see some of my stylesheets. Any comments appreciated. Thanks
Richard, I will try some tests of a yellow background as well and
green-orange. I have 500,000 words online to play around with, six
stylesheets and plenty of mistakes I would appreciate someone pointing
out any error in my ways.

http://www.hereticpress.com/Dogstar/Access/index.html

Long way to go

Tim
http://www.hereticpress.com/index.html


Richard Quick wrote:

For a very good example of what you're doing take a look at:

http://www.kent.ac.uk/guidance/disabilitysupport.htm

My girlfriend has poor eyesight and found the yellow background much easier
to read. I know people with Dyslexia often find green or orange tints
easier as well.

"DarthMcAdam" <adam (AT) adsandtaz (DOT) com> wrote

Richard,

Thank you for your recommendations; I will look to incorporate these
into the final version of my artefact. As per my reply to Pam, I need
to take a slightly different approach for my dissertation, as it seems
that the crux of this matter is actually in how the original HTML is
coded, as you've rightly pointed out, and not the aspect of being able
to dynamically change the style sheet associated with the page.

Changing the CSS is not a bad thing per-se - it's just not everything.
Remember accessibility is about making using your website easier for all
disabled people, not just those with one disability.

You've got to take account of:
Blindness
Partially-sightedness
Colour-blindness
Dyslexia
Deafness
Learning difficulties (have you used the simplest language possible? Have
you used icons as well as text?)
Motor control difficulties (not being able to use a mouse)
Epilepsy
ADD

and lots more...

Changing the CSS can help partially sighted people, dyslexics and those with
colour-blindness. So use it - just don't forget about blind people or
prople who can't use a mouse.

I had hoped that the text only version would be more easily accessible
to screen readers (probably as a result of not knowing enough about how
they worked), but this has not proved to be the case. It has therefore
become apparent that the benefit is more applicable to partially
sighted users, as you've suggested.

Having looked at the source code for the default and text-only versions
of your site, am I right in thinking that you've actually delivered two
different pages?

No. They deliver the same code with 2 small exceptions.

1. The CSS file which is called is different.

2. When the user first switches to the text-only version of the site some
info about acceskeys etc is displayed at the top of the page. However on
subsequeent page views this info is removed.

There are also a few minor text changes, but essentially the html is the
same for the text and visual versions of the page.

Although I was trying to utilise the same HTML code
in all instances, it's clear that this is not suitable unless it is
coded in such a way that it will be perfectly accessible where no style
sheets are associated with the page.

I look forward to your response.

The idea of CSS is that it separates the structure of the page from the look
and feel.

What you should do first of all is create an html page that is well-coded
and accessible. Then you use CSS to style it.

It never works out quite like this in practice, but still you should be able
to create a CSS page which is accessible as well as attractive.

On the CATA site I actually put in the text-only version mainly as a
cover-all (for people who were using older browsers, unforeseen disabilities
etc). However from all the user-testing we did blind people didn't need to
switch to the text-only version to access all the site's functionality
(where the screen reader accessed the DOM at least - e.g.. JAWS).

The main thing to consider is how the site renders with no CSS. For
instance is the most important information first? Is the order logical? Is
there in page navigation?

That's why on the CATA site the central column appears before the left
column in the code.

Using headings, paragraphs and lists properly goes a long way to achieving
this.

Also consider how things will be read out by a computer. E.g..
Abbreviations, telephone numbers etc.


--
Richard Quick
http://www.chocolatemagazine.co.uk

I have come to the conclusion that "finding ways to make Web pages more
accessible and more usable for people" is an ongoing journey that I
will never complete as there is always something more to learn. I have
been lucky to have found friends along the way to help me understand
and there are a number of tools that are available.

I generally use Firefox with a few accessibility extensions.

Web Developer -- http://chrispederick.com/work/firefox/webdeveloper/
Fangs Screen Reader Emulator -- http://sourceforge.net/projects/fangs
CLC-Fire Vox (new screen reader for Firefox) --
https://webspace.utexas.edu/chencl1/clc-4-tts/
HTML Validator --
https://addons.mozilla.org/extension...umpg=10&id=249

There is also a Web developer's toolbar for Internet Explorer, which
has some basic tools to check pages for people with colour blindness --
http://www.nils.org.au/ais/web/resources/toolbar/

Desktop VIS is an awesome tool that allows you to see what applications
running on your desktop might look like for people with numerous types
of vision impairments -- http://cita.rehab.uiuc.edu/software/vis/

The developer's toolbars allow you to turn off the style sheets so you
can see what a page looks like without them. The toolbar in Firefox
allows you to edit a page's style sheets (locally) so you can
experiment or customize what the page looks like. The toolbar in IE has
links to useful tools. Gez is converting his Juicy Studio tools from
ASP to PHP (his entire site, actually) so you might get a "page not
found" message. Be patient; they will be available again shortly.

Regarding Richard's comment " Learning difficulties (have you used the
simplest language possible?", I had run my "About This Site" page --
http://www.the-bifurcation-point.com...nly/about.html --
through the Readability Test on Juicy Studio a couple of months ago.
It's at about a 10th grade reading level, which could cause a problem
for some people. I think an 7th to 9th grade level is more appropriate.
Because I use my site to demonstrate concepts regarding accessibility,
I leave it as an example.

If you want to see the difference between fixed-width pages and
fluid-width pages, feel free to compare the link in the previous
paragraph with this link --
http://www.the-bifurcation-point.com...l/nek/bio.html

The pages regarding the Bifurcation Point are fluid. People can easily
read them on a handheld device. The pages about Nek have a fixed-width
in the style sheet. Screens with widths less than 52 or 53 em will
scroll horizontally.

Because many people I work with have not yet gotten into server-side
techniques, all the pages on my site currently use techniques through
markup and styling that should work in most browsers. Juicy Studio is a
site that uses more server-side techniques to improve accessibility and
usability.

Richard also mentioned "Also consider how things will be read out by a
computer. E.g.. Abbreviations, telephone numbers etc.". Listening to
how Fire Vox reads pages should give you a good idea about this. I'm
helping a friend with her Web site. When Fire Vox reads "St. Gabriel
Records", it sounds like "street Gabriel Records". I've suggested to my
friend that we spell out (rather than abbreviate) Saint everywhere on
the site.

Let me gather some more of the examples I've used for instructional
purposes and I'll post the links for them as well.

Pam