Re: Replace aria-datatype and evolve contenteditable

When will the Web Forms 2 datatypes appear in HTML 5?

How do they differ from XSD data types?

What browsers support the Web Forms 2 data types today?

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist
Chair, IBM Accessibility Architecture Review  Board

             "Simon Pieters"                                               
             >                                                          To 
             Sent by:                  public-html <>,   
             public-html-reque         ""                 
             05/08/2008 10:00                                      Subject 
             AM                        Replace aria-datatype and evolve    

This email contains two related rough proposals/thoughts for the ARIA spec

and the HTML 5 spec:

   1. Replace aria-datatype with something that works in HTML.
   2. Perhaps evolve HTML 5 contenteditable to support WF2 features.


aria-datatype seems to be incompatible with HTML requiring QNames with
associated namespace declarations being in scope, since text/html doesn't
support namespace declarations. (Moreover, it's unclear how to implement
aria-datatype and XSD seems suboptimal; see


For ARIA, I'd suggest to align with or adopt data types in Web Forms 2.0,
in particular <input type=email>, <input type=url> and the pattern=''

(The other values for type='' are not really appliciable, AFAICT.)

Since ARIA datatypes are, AIUI, expected to be used on any user editable
region, including <div contenteditable=true>, this begs the question as to

whether HTML 5 should adopt WF2 type='email', type='url' and pattern=''
for contenteditable elements as well. Either they are useful for
contenteditable, and HTML 5 should have them, or they are not, and ARIA
should restrict its data types to HTML <input> (and <textarea> for
pattern='') (in which case, ARIA can simply drop aria-datatype and let the

above WF2 features replace it, or adopt the WF2 features without aria-
prefix as with tabindex).

If the former, then should readonly, disabled, required, etc. also apply
to contenteditable? It would make sense as far as AT exposure goes, but
contenteditable doesn't take part of WF2 form validation or submission, so

it would be a bit inconsistent. Perhaps there should be an attribute on
<div> saying that the element is a form control that accepts normal form
control related attributes and takes part of form validation and, if the
element is successful, submits its innerHTML. (Same with <iframe> in
combination with designMode, submitting its contentDocument.innerHTML?)

Simon Pieters
Opera Software

Received on Thursday, 8 May 2008 18:53:07 UTC