Login dialog strawman based on IIW discussion

[Terrell Russell]

Johannes Ernst wrote:
> Good input! Would you like to write this up in a few SHALL /  
> SHOULD / .. kind of sentences? ;-)
> 

A relying party (RP) SHOULD try to minimize clicks for returning
OpenID-using visitors by showing the single OpenID login box by default.






Any use of OpenID by US Federal entities SHOULD be Section 508 compliant.

I've pasted below the most pertinent part of Section 508 (relating to
forms on web pages).  "Section 508 speaks to various means for
disseminating information, including computers, software, and electronic
office equipment. It applies to, but is not solely focused on, Federal
pages on the Internet or the World Wide Web. It does not apply to web
pages of private industry."


> On Dec 10, 2006, at 20:19, Terrell Russell wrote:
> 
>> Johannes Ernst wrote:
>>> Updated at http://netmesh.info/jernst-files/openid/login-dialog.html
>>>
>> Looks good - we're getting there quick...
>>
>> And don't forget your alt and title messages (for hover information).
>>
>>
>> Also...
>>
>> Not a part of the visual interface as such - but it seems nice to  
>> have a
>> cookie, if the user allows it, that remembers whether they logged in
>> with an OpenID the last time they visited.
>>
>> If they logged in with OpenID most recently, then the OpenID login
>> should be the default prompt - not the user/pass.  It saves a click  
>> and
>> reinforces the 'normalness' of seeing the OpenID single login box.
>>
>> Terrell
>>

From:
http://www.section508.gov/index.cfm?FuseAction=Content&ID=190

1194.22 (n) When electronic forms are designed to be completed on-line,
the form shall allow people using assistive technology to access the
information, field elements, and functionality required for completion
and submission of the form, including all directions and cues.
What does this requirement mean?	
Terms and Definitions
field element – a user interface element that appears within an
electronic form field.
Assumptions	
Assume that informed humans can reasonably consistently judge whether
the order in which the information is presented in a form is logically
correct.
How can I tell if this requirement is met?	
Identify all information, field elements, and functionality that are
required for completion and submission of the form.

1.	Inspect web content source to help identify form functionality, for
example in HTML look for the element <form>.  Verify that the form
functionality is accessible.  Some examples of accessible approaches to
various form element functionality include:
a.	For selection menus (or drop down boxes), radio buttons and check
boxes- to ensure that AT user can ascertain the options being presented
by these elements as well as determine/ edit choice marked.
b.	For edit boxes (text fields and text areas): be able to relate label
to entry area and enter / verify text entered.
c.	For buttons (like reset, submit):  be able to determine their purpose
and activate them.
d.	For forms embedded in data tables: be able to associate the column
header and row header with a text entry cell in the form.
e.	For instructions: be able to navigate/access the instructions
relevant to the part of the form being filled and return to that part.

Note: Some design features of an electronic form generally facilitate
access to assistive technology, such as the relationship between control
labels and controls or the sequence/ordering of form fields and
directions or cues.  Look for the attribute named  “tabindex” – if used,
the sequence of this attribute should be the same as the optimal
sequence for a user moving through the form.  Note that some browsers
cannot tabindex.


Note: Labels should be associated with input fields in the HTML using
the explicit <label> tag - this association is what is required by
assistive technology.  If this is done, the placement of the label for
display on the page is not relevant for assistive technology.

2.	Apply AT to make sure screen readers get information in correct
order.  Note the use of AT as a measurement method is limited by the
adequacy of algorithms and heuristic methods of the specific AT tool
used.  It can be used to identify problems with specific AT-E&IT
interoperability but it cannot predict results with other AT or with
other versions of the same AT, OS, application or accessibility
architecture.  AT should include the full range e.g. screen readers,
screen magnifiers, alternate input devices, etc.

Note: When forms are used together with tables, some screen readers can
have a conflict with select boxes, permitting the user to select more
than one choice in a list.

Note: Satisfying this requirement supports interoperability with
assistive technology such as screen readers or screen magnifiers.
Where can I get additional information?		
1.	Guide to the Section 508 Standards for Electronic and Information
Technology, Web-based Intranet and Internet Information and Applications
(1194.22), Updated: June 21, 2001,
http://www.access-board.gov/sec508/guide/1194.22.htm#(n)
2.	The W3C WAI User Agent Accessibility Guidelines 1.0 Checkpoint 2.1
provides further guidance and techniques for this requirement, at
http://www.w3.org/TR/UAAG10/guidelines.html#tech-doc-content-access
3.	The W3C WAI User Agent Accessibility Guidelines 1.0 Checkpoint 2.3
provides further guidance and techniques for this requirement, at
http://www.w3.org/TR/UAAG10/guidelines.html#tech-conditional-content
4.	The W3C WAI maintains a listing of various tool and services
available for evaluation and repair of web pages for web content
accessibility, at http://www.w3.org/WAI/ER/existingtools.html
5.	An example web page illustrating typical violations of this provision
can be found at http://projects.accessibilityforum.org/demos/Rule_n.htm