decloak logo
Cart cart | sign out  
css versus tables
 css vs tables: round I. 
    1. benefits to css
 
    2. is full css faster
 
    3. Return on
Investment
 
 
    4. Long Run
Maintenance
 
 
    5. w3c standards
are useless
 
 
    6. structure
and content
 
 
 
 css vs tables round II. 
    7. point:
        tables are for
       tabular data...

     counter point:
       yes, but tables
       make up
       databases.
       Duhhh!!!








    8. Hey Stupid
 
    9. Bandwidth Savings
 
    10. accessibility and
     $4000 wheelchair
     ramps
 
 
 
    11. Spend Time
Learning
 
 
    12. Captured
CSS Flagship
 
 
    13. Selling your
product
 
 
    14. May work well
 
    15. Standards
Merry Go Round
 
 
    16. Extremists
Update
 
 
 
 
  
   
 
    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.


  1. 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.

    The 1 x 1 pixel alt tag problem for screen readers.

    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.


  2. 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?

  3. 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.

  4. 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?


flush lines that auto stretch vertically and horizontally
 
terms of use | privacy policy
copyright © 2003 - decloak, inc. all rights reserved