WEBINAR SERIES: ACCESSIBLE INTERACTIVE DOCUMENTS Week 3: Accessible Web Forms Norman Coombs

1. WEBINAR SERIES: ACCESSIBLE INTERACTIVE DOCUMENTS Week 3: Accessible Web Forms Norman Coombs Norm.Coombs@gmail.com

2. TODAY’S AGENDA • What’s the problem? • Legislation and standards • Screen readers and forms • Text boxes, label, id and input • Required fields and errors • Check boxes, fieldset and legend • Scripts needed to process the data input • Practice exercises

3. WHAT ARE FORMS FOR? • "An HTML form on a Web page allows a user to enter data that is sent to a server for processing" • "...Web users fill out the forms using checkboxes, radio buttons, or text fields. • Script commands on the page or on a server then processes the data

4. HOW DO FORMS WORK? • The HTML code in the Web page requests input from the user • Other HTML code accepts the user’s input • All the HTML form code must convey the request to the user and then permit the user to respond using the keyboard

5. WHAT’S THE PROBLEM? • A survey of over 20,000 university Web pages found that less than 29% of the Web pages that have form controls use proper labeling for accessibility • Creating Web forms that are accessible to people with disabilities requires understanding of the labeling features of HTML markup and how browsers interpret labeling markup for assistive technologies

6. GUIDELINES AND STANDARDS • Web Content Accessibility Guidelines(WCAG2): perceivable, operable, useable robustwww.w3.org/TR/WCAG/ • The Federal Rehabilitation Act, Section 508www.section508.gov/ • Illinois Accessibility best practices http://html.cita.illinois.edu/

7. THE INTENT OF WCAG GUIDELINE 2.4 • For finding, navigation, and orientation, it is important that the user can find out what the current location is • For navigation, information about the possible destinations needs to be available • Provisions need to be taken to ensure that screen reader users can successfully navigate the content • Unusual user interface features or behaviors may confuse people with cognitive disabilities

8. THE INTENT OF WCAG GUIDELINE 3.3 • Everyone makes mistakes. However, people with some disabilities have more difficulty creating error-free input • This guideline seeks to reduce the number of serious or irreversible errors that are made, increase the likelihood that all errors will be noticed by the user, and help users understand what they should do to correct an error

9. ACCESSIBILITY FOR WHOM? • Form accessibility primarily refers to screen reader users • Secondarily it may concern users with cognitive difficulties and some users with motor control issues

10. BASIC WEB ACCESSIBILITY Accessible forms must be on Web pages that meet general accessibility principles • Well organized • Clear language • Good foreground and background contrast • Crisp easy-to-read font • Images have alternative text • All controls are keyboard accessible • Simple, clear page navigation

11. SCREEN READERS AND FORMS • The form must convey the necessary form information to the screen reader and its user • The form must enable the screen reader and its user to interact effectively with the form and to know that the desired action was performed successfully

12. FORMS AS BLACK HOLES! What I heard in one form asking for info on students • First Name • Last Name • Edit • Edit • Edit • Edit • Edit • Edit

13. DROP-DOWN MENUS ACCESSIBILITY • Drop-down menus like forms should be Keyboard Accessible, Logical, and Easy to Use • The problem is when the menu utilizes the 'onchange event' script • Moving between items trigger the action without the user having actually selected it

14. HTML CODE FOR FORMS • Most people creating Web pages, who are not professional designers, create the HTML using a WYSIWYG application like Dreamweaver and know little if any HTML • Knowing some HTML code related to forms will help you both in authoring and checking the WYSIWYG output, but we will keep it to a minimum

15. FORM: LABEL, INPUT & ID ELEMENTS 1 • Sample HTML code <label for=“first">First Name</label> <input id=“first" type="text" name="text33" size="12"> • The text with the label element tells the user that the form wants a first name • Input and text indicates that the form is requesting a text input

16. FORM: LABEL, INPUT & ID ELEMENTS 2 More HTML code explanation: • The label and id elements both are related to the word “first” which is in quotes and connects the label and the id together • The input element and type=text indicates it is looking for text input • The size specifies the size allotted to the text box

17. FORM: LABEL, INPUT & ID ELEMENTS 3 Still more HTML code explanation • <input id=“first" type="text" name="text33" size="12"> • The name element in this line of code actually will help the form talk to the form processing script on the server • Forms have to talk to script on a server to process the form such as emailing its data to a user

18. REQUIRED FORM FIELDS 1 Required form fields need 2 things to work properly: • The form has to interact with script to process it and to check that the required input was activated • The form has to convey to the user that the field is required and that needs to be accessible to screen reader software

19. REQUIRED FORM FIELDS 2 • The form script is beyond this Webinar which is limited to HTML • HTML code example: • <label for=“first">First Name (required) </label> • The text displayed to the user now reads “first name (required) instead of only “first name”

20. REQUIRED FORM FIELDS 3 • Some designers dislike the text “required” being visible and instead mark the field with the color red or an asterisk • Accessibility can be achieved with an image with an alternative text • This could be totally invisible with a 1-pixel image the same color as the background

21. ERROR CORRECTION • This is also done by script • The script recognizes a required field is left blank • Then a page is displayed indicating what was missed and returning to the form

22. ACCESSIBLE CHECK BOXES The items below are identified as radio buttons. The input element will let the user check or uncheck it • <input type="radio" id="male" name="gender" /> • <label for=”male”>Male</label> • <input type="radio" id="female" name="gender" /> • <label for=”female”>Female</label>

23. FORM ELEMENTS: FIELDSET AND LEGEND 1 • The fieldset element is used to group items in a form • The HTML legend Element represents a caption for the element in the fieldset • Fieldset and legend elements should always be used together • They allow you to create and name groups of related input fields in a forms • By doing this you help users understand how the input fields are related

24. FORM ELEMENTS: FIELDSET AND LEGEND 2 • The first line of the grouping of related elements begins with <fieldset> and the last line ends with </fieldset> • The legend provides a title or description for the grouping<fieldset><legend=“Which fruit do you prefer?” </legend> • (then your group of check box items) • </fieldset>

25. FORM ELEMENTS: FIELDSET AND LEGEND 3 • <fieldset> • <legend>Gender?</legend> • <input type="radio" id="male" name="gender" /> • <label for=”male”>Male</label> • <input type="radio" id="female" name="gender" /> • <label for=”female”>Female</label> • </fieldset>

26. ONE PEAK AT FORM SCRIPT • <form action= http://dummy.com/php/test.php method="post"> • <input type="hidden" name="submit_to” value="Someone@somewhere.com"> • (the form content goes here) • <input type="submit" value="Send"> • <input type="reset" value="Reset"> • </form>

27. PRACTICE MATERIALS • The archive resource page for this Webinar will include a link to a zip file which contains sample Web pages for you to edit and practice what you learn: • http://easi.cc/archive/accessible-forms2013/resources.htmm

28. RESOURCES FOR MORE ADVANCED FORMS • WebAIM: http://webaim.org/search/?q=accessible+forms http://webaim.org/standards/wcag/checklist • U. of Illinois best practices: http://html.cita.uiuc.edu • Web Content Accessible Guidelines http://www.w3.org/WAI/guid-tech.html