|
|
|
|
|
|
POINT:
Use
Fully Integrated CSS for Accessibility
Reasons.
COUNTER
POINT:
Use
some COMMON SENSE and simple solutions before
spending
billions of dollars to fix
something that's not broken to begin with.
- A
spacer gif is typically a 1 by
1 pixel, but W3C standards and
508 Guidelines say you have to have
alt="" to
represent a null.
Just exactly what text can a person read
or see in a 1 x 1 pixel gif?
ANSWER: Zippo.
(And even if the 1 x 1 pixel gif is stretched to act as a border or spacer, e.g. 1 x 200 or 200 x 200, the pixels are still the same color or transparent color designation, so it's ZIPPO to read again.)
What about custom bullet images for lists? Should those have to have alt tags descriptions?
Or corner images to make rounded tables?
What about background images that are just simple gradients?
Or custom decoration images?
Should all these have to be described in an alt tag?
Exactly what benefit will these to be a blind person and will this benefit take away from the time needed to sound out the main content of the page? Yes and so the text reader should be used wisely.
Thus, the text
or line reader, JAWS, cynthia, etc, should
be smart
enough to see that the image size of Height="1" and
Width="1" and automatically know
it's a spacer and then make a if-then
condition to NOT PRONOUNCE alt tag in
the spacer.gif.
It's like, what word can you put on a
1x1 pixel anyway that needs to be read?
Can you put the entire manuscripts of
Shakespeare on a
1x1 pixel image? How
about a lost painting from Rembrandt
on a 1 x 1 pixel?
Here is the code written in C, Java style
for that solution below.
if
( width == 1 && height == 1
&& src.indexOf("spacer.gif"
> -1)
) {
//
skip the spacer tag and don't process this
//
alt
tag as it's too small
to see anything
//
in the first place. Apparently, CSS
zealots and
//
screen/line reader software companies
seem
to
//
think there is some hidden text, (like some
//
forgotten Shakespeare script), on
a 1 x 1 pixel
//
and that screen/line
readers software should
read
//
the alt tag attribute
anyway to the disabled.
//
like what letter of the alphabet can you fit
//
on a 1 x 1 pixel? NOTE the period "." is not part
//
alphabet
return;
}
elseif (colorForAllPixelsAreTheSame() == true} {
//
skip the spacer tag and don't process this
//
alt
tag as all the pixel colors are the same anyway and so
//
nothing to read in the first place.
)
else {
//
process this image and try to read
//
the alt tag is
there is any!!
pronounceTheAltTagMethodToDisabledPerson();
}
So, it should just skip it anyway
and don't
say anything to the disabled person.
Even the 1 x 10 pixel of the 1 x
100 pixel and so should still be
skipped.
Is there something on the 1 pixel
wide column or row that can
be read? NO.
Apparently,
it seems the word hasn't gotten out
on how simple this is to the CSS
elitist consortium and/or the text/line
reader software companies. There
should be no more complaints about
this nonsense.
- This
is an indirect reason for using CSS hence <DIV> tags.
However, let's say a web designers uses a FULL CSS solution. Will that really
make it easier for non-visual browsers to read? You will still have to label
each and every section of each and every page anyway with a unique name anyway.
And having lots of articles won't make it any easier for CSS. And if you have
to label each and every section with a unique ID or NAME regardless of whether
you use CSS-P or not, the non-visual browser can easily tell what it is and
where it should go via a standard prefix in the name.
example
<table>
<tar>
<td width=80%" id="BODY__ArmstrongWins5thTourDeFrance">
It's the same for all these IMG tag, they need to be labeled as well.
If anything, these non-visual browsers need to more intelligent and not dictate
to 99.99% of the population on how to surf. Accordingly,
...reminds
me of the $4000 wheelchair ramp for the front of the building when
there
is already a ramp in the rear of the building. Or the $4000 handicap
ramp for the lemonade stand. A complete waste of taxpayer's dollars.
What's really stupid is that these non-visual browsers aren't smart enough
to figure out what the words mean or have some idea what they pertain
to? There is a spell checker and a GRAMMAR checker in Microsoft Word.
So what
is really that much different in a web page that a non-visual browser
can't apply a little artificial intelligence to understand the web page?
See how a simple solution via a prefixed name can easily solve
this accessibility problem instead of some over blown and time
consuming solution such as fully
Integrated CSS (<DIV>)
tags.
It's millions of times
cheaper and faster to have a single programmer update a popular screen
reader
or non-visual browser to look for that ID attribute in the <td> tag instead of having millions of web designers in the entire world do a complete
redesign of their entire website.
If any government agency does it this way, it shows you the complete waste
of taxpayer's dollars. i.e. Accessibility 508 for government websites.
Congress should have just appropriated money or given tax credits and
incentives to build a special "smarter" browser
just for these people instead wasting billions of dollars on I.T. to convert
all of their government .gov websites to be accessible. A few million dollars
vs. hundreds and hundreds of millions?
- DEAR SCREEN READERS SOFTWARE MAKERS like JAWS:
HERE IS SIMPLE SOLUTION so EVERYONE WILL
NOT HAVE TO RE-WRITE THEIR PAGES just for
you.
READ THE BIG TEXT FIRST, either font tags
with say 3 to 7, or CSS styles with the
biggest
fonts sizes.
Next,
read the 2nd largest fonts second, and
so on. This is JUST LIKE WHAT HUMAN WOULD
DO ANYWAY.....So, look for Font tags
with a setting 7 or 6 or 5 or 4 and down
and in that order and then start reading
it. Same with CSS, PIXELS sizes of say
24px should be read FIRST, NOT LAST!! How hard can this be? This what the browsers do anyway, so why can't you do
it?
Screen
readers think they are SMART by just reading
the Heading tags first e.g. <H1>. However, web designers and developers rarely use <H1> or header tags anyway.
Well, what screen readers should really
do is automatically read text that
is
BIGGER
than the text
below it or around it. How hard could
that be to program? Not hard at all.
Just have
have
the screen
reader do a text size comparison just
like the browser does. If this text
is much
bigger than the surrounding text, then
that's what the screen reader should
be
reading first as the header
Imagine you are on the phone with a
friend and you have no access to a
computer and
you
tell your
friend to go to a web page for info
that you need. First your friend should
be smart
enough to scan the page first and give
you the relevant info anyway...that's
the type of thinking that
should be developed into screen readers..and
it's not that
hard.
- Another thing with the IMAGE tag. Do
we really need LONGDESC tag, i.e.LONG
DESCRIPTION?
Can't the screen reader already know
the length of the description in the
first
place before reading it? Just have the
screen reader have a default number
of words to read in the first place and
ask
the user if they want to continue reading
or tell them that it's so many words
long and then ask them a question whether
to
read through it.
Where is the intuitiveness and innovation?
Just who is making this screen reading
software in the first place?
|
|
|
|