=========== EXPLANATION =========== what follows are specific comments on the markup used in the extant form, as well as specific descriptions of the changes i made, as well as the reasoning behind the changes. what prompted this effort? first, the complaint that provoked this automated response concerned both the inaccessibility of certain portions of the gmail interface, as well as the lack of responsiveness on the part of google slash gmail in addressing these issues, even when SPECIFIC corrections slash changes slash improvements have been offered, and despite the existence, for 6 years, of guidelines for the proper implementation of web-based standards that ensure (or, were, at least intended to ensure) access to the web for all and by all. second, when i received my chance to provide feedback about my attempts at interaction with the gmail-support team about the accessibility of the portions of the gmail interface, i quickly discovered that the survey to which i was supposed to reply was, itself, inaccessible. how so? 1) use of invalid markup; 2) use of TABLEs rather than stylesheets to control layout; 3) use of TABLE-ized FORMs; 4) FORMs that lack the programmatic binding mechanisms introduced in HTML4 which provide context for individual form controls - namely, FIELDSET, LEGEND, and LABEL - without which the extant survey can only be understood by someone capable of visually processing the page as an organic whole (there is no "gestalt view" when one's ability to process visual phenomena is either compromised or non-existant) you should NOT use TABLEs to visually slash graphically slash spatially format pages, using invalid code, empty columns and rows, and spacer images; TABLEs are a visual construct that only have meaning inasmuch as the user can discern the relationship between disparate pieces of data and their relationship between an item of data and the labelling/contextual information associated with that item of data on the X and Y axis, which is why TABLE-ized information - especially if used to render a FORM -- MUST use the programmatic features built into HTML since version 4.0 (and which are built-into XHTML) to programmatically bind each FORM control with its textual label and to programmatically indicate to which question a particular grouping of answers belongs. for fully functional examples of the feedback survey form, please consult the following long URIs, the beginning and ends of which are demarcated by brackets: index - Links to Reformats & Resources [http://www.hicom.net/~oedipus/temp/google/gmail/accessible_feedback_form_options.html] option 1 - De-TABLE-ized FORM in FIELDSETs with LABELs [http://www.hicom.net/~oedipus/temp/google/gmail/ts_gmail_gjr.html] option 2 - De-TABLE-ized Document with FORM in FIELDSETs with LABELs: [http://www.hicom.net/~oedipus/temp/google/gmail/ts_gmail_gjr2.html] option 3 - De-TABLE-ized Document with FORM in "hidden" FIELDSETs with LABELs: [http://www.hicom.net/~oedipus/temp/google/gmail/ts_gmail_gjr3.html] (note: of the 3 options, i would strongly recommend the second, however, i accomodated the tablization of the introductory materials in option 1, in keeping with the current design structure of Gmail, which uses TABLEs for layout; in Option 2 and Option 3, i controlled layout through the use of the DIV element and the use of CSS to control placement, flow, etc. - all of the reformats validates against the World Wide Web Consortium's Document Source Validator, which is located at [http://validator.w3.org] =========================== CHANGES MADE TO EXTANT FORM =========================== [Note: the following also appear as comments in the document source of the reformatted feedback forms; i collated and collected them here for your programmers' convenience. to find them in context, in the document source for each reformat, search for the string "GJR" (all capitals, without the quotes)] 1. the original lacked any DTD (Document Type Declaration); i added the HTML 4.01 DTD to each iteration of the feedback FORM, since that is what the original source code is closest to. 2. added natural language identifier for the HTML element; i would strongly encourage the use of the natural language identifier on ALL google slash gmail interfaces, so that User Agents, Assisstive Technology, and browsers of all stripes, kinds, and modalities can render charsets and directionality correctly, not to mention load pertinent and appropriate pronunciation rules and dictionaries (if the lang attribute is used, for example, my screen-reader will, if i so set it, switch on the fly to the correct language (with all of its corresponding pronunciation tables, customized dictionaries, etc., if the language indicated is supported by my screen reader, JAWS, which currently supports 10 natural languages to declare a page's natural language, use the following markup: to indicate a string of text in the body of a document, enclose the string in a SPAN container, and use the lang attribute to indicate the switch in natural languages; if you link to a page that is in a different natural language, use the 'hreflang' attribute to indicate the natural language of the target page; and, naturally, if the hypertext that points to a non-english page is not in english, use the 'lang' attribute as part of the A element to indicate the natural language of the hyperlink text 4. added charset and content-type declarations to HEAD element: 5. added missing (and required) 'type' attribute for STYLE element: 11. removed the following attributes from the BODY element: --- begin list of attributes removed from BODY element bgcolor="#ffffff" text="#000000" link="#0000ff" vlink="#30656b" alink="#ff0000" --- end list of attributes removed from BODY element they should be defined inbetween the STYLE tags in the HEAD section. 12. removed the following attributes from the BODY element: topmargin="20px" leftmargin="40px" rightmargin="40px" because they are: (a) invalid and (b) should be defined in the stylesheet, as should ALL of the attributes for the BODY element and the A element 13. why is a TABLE used to layout this form? there is far more robust, not to mention valid and accessible, markup built into the HTML 4.x slash XHTML 1.x specifications for binding groups of related controls (FIELDSETs), providing contextual information for a group of related controls (LEGEND), and programmatic means of associating specific text with a specific form control (LABEL) 14. there should ALWAYS be at least one level 1 heading on a page; therefore, i changed the text-string "Gmail Support Survey" from simply another paragraph to what it actually is, an appropriate (and necessary) level 1 header for this page 15. control placement, size, padding, etc. of the IMG element using stylesheets - at least use the 'style' attribute, although defining style in a dedicated stylesheet or within the STYLE element in the HEAD allows for greater user control 16. replaced all instances of deprecated B element with STRONG and 17. added 'intro' class which is defined in STYLE container in HEAD 18. why is the text-string 'Google's privacy policy' not a hyperlink pointing to Google's privacy policy? 19. why not explicitly state the number of questions on the form in the intro paragraph? 20. FORM comment: you MUST enclose attribute values in quotation marks 21. simple to automate the id/for associations for forms - what i did was to follow the simple formula: question 1 id="q1" for="q1-ax" where 'x' stands for the number (x) of (y) with 'y' being the total answers possible for the question being asked 22. not only replaced deprecated B element with STRONG, but properly identified the questions as the LEGEND for the FIELDSET of FORM controls to which it pertains.