(Inactive) Web Best Practices: Teleconference Details

Teleconference details


Event handler rules
  • Clarify severity of the rules: http://html.cita.illinois.edu/script/onmouseover/onmouseover-rules.php
  • The best practices documentation says the onmouse over and onmouse out rules are pass/warning. FAE and Firefox Accessibility Extension report them as pass/fail. The documentation on any discussion of the rule is not clear about any possible decision on changing the severity level from fail to warning .
  • Revisit the rules to determine the severity level

Headings in forms discussion

Date input form control best practices


  • Tim Offenstein, UIUC
  • Jon Gunderson, UIUC
  • Jim Wilson, UIUC
  • Nick Hoyt, UIUC
  • Mike Scott, DHS
  • Melissa Romanotto, DHS
  • Jamie, DHS
  • Scott Rohde, OJC
  • Hadi Rangin, UIUC
  • Robert Slater, UIUC
  • Dan Grauman, NIH

Event handlers
  • Major issues are javascript adding event handlers and parent may contain keyboard event handlers
  • Example is the DHS website uses some of these techniques, but uses javascript and therefore automated tools do not detect
  • An example is a link inside of a list item, the mouse over on an LI element and the onfocus on the A element
  • Harper college is an example of this stylistic techniques: http://harpercollege.edu
  • Cases:
    • Parent/child event handlers
    • javascript adding
  • We can only know about attributes
  • Overal is a muddy issue
  • The best practices are different than the FAE rules, since FAE can only detect attributes and not event handlers
  • IITAA point of view it concerns about certification
  • Suggestion to move to a warning or check
  • We want to have stability with the rules
  • If we could identify the situation correctly we want to fail
  • Proposal to have them be warning
  • One of the definitions of warning is that they could fix the problem
  • The Harper example they could fix it
  • Are there examples of how this is a problem
  • Visual to see where there is keyboard focus
  • Drop down menus
  • Problem for keyboard only user
  • DHS would use a structured approach for screen reader compatibility, so the keyboard support is mostly for keyboard only users
  • Other examples are context sensitive help systems
  • Is the limitation of testing for attributes important enough for a rule?
  • I think it is
  • What about the parent child relationship
  • How does harper effect the screen reader user?
  • No effect, the problem is for keyboard only user
  • They do not have children
  • RESOLUTION: The evaluation criteria will change from pass/fail to pass/warning

Header Discussion
  • Jon Gunderson talks about the dense survey questions
  • Concerns that the radio buttons are a poor way
  • Are there arguments for use drop downs
  • Are there usability issues with drop downs
  • Drops downs can not be seen all at once, there is an extra click
  • There is the scantron form model of users that is familiar
  • Radio buttons are small targets for people to select
  • People are reluctance to click on drop downs, people would go to find a different tool that does the radio buttons
  • Can we have it configurable, radio or select??
  • There maybe authoring issues of radio versus select box system
  • Drop down are better than radio groups from an accessibility point of view
  • It makes sense to Hadi
  • What about the number of clicks for a person with a disability? radio buttons take a lot of clicks
  • How do you get the idea of the gradient in a select box
  • You could put text markers in the option element and not just not numbers
  • The low is at one end and high at the other end
  • Select boxes

Automatically move focus unexpectantlly
  • The auto focus moving feature trips people up all the time
  • It is probably ok for people who use the same forms
  • Use a single field for dates and time, use scripting to read the various formats