Closed Bug 389230 Opened 17 years ago Closed 13 years ago

Support datatype object attribute for <xul:textbox type="number">

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: aaronlev, Assigned: surkov)

References

(Blocks 1 open bug)

Details

(Keywords: access)

Attachments

(1 file, 1 obsolete file)

patc2
31.85 KB, patch
aaronlev
: review-
Details | Diff | Splinter Review 
Any time we know something about the datatype of a form control we should expose that information.

See http://wiki.mozilla.org/Accessibility/Datatypes

For <xul:textbox type="number"> we should expose the datatype object attribute.

In the future this will help people with physical disabilities that use alternative input tools. It allows onscreen keyboards to simplify access for the field, and allows voice input software to limit the current possibilities, which increases accuracy.
Attached patch patch (obsolete) — — Splinter Review 
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED

        Attachment #273548 -
        Flags: review?(aaronleventhal)

    
    

    
  
(In reply to comment #0)

> See http://wiki.mozilla.org/Accessibility/Datatypes

Is the page is up to date? I mean for xforms we expose 'datatype' area attribute, the page suggests to expose 'xs-type'.

Also, Aaron, do you want to expose the following attributes too for numberbox:

xs-totaldigits
xs-fractiondigits
xs-valuemin
xs-valuemax

Right? Do we need to use 'xs-' prefix?

    
    

    
  
I don't know. Yes, I was thinking it was a good idea to put those in because it's easier to see all of the datatype-related object attributes. Otherwise, it might be hard for developers to understand that all of these object attributes belong together? What do you think?

Do we know any of the answers to xs-totaldigits, xs-fractiondigits, xs-valuemin or 
xs-valuemax?

    
  

        Attachment #273548 -
        Flags: review?(aaronleventhal) → review+

    
    

    
  
(In reply to comment #3)
> I don't know. Yes, I was thinking it was a good idea to put those in because
> it's easier to see all of the datatype-related object attributes. Otherwise, it
> might be hard for developers to understand that all of these object attributes
> belong together? What do you think?

I have the questions only. Who wants to use these attributes? Who will provide these attributes excepting us?

I'm not sure we should expose xs-type/xs-valuemin/xs-valuemax because there are similar ARIA properties.

> Do we know any of the answers to xs-totaldigits, xs-fractiondigits, xs-valuemin
> or 
> xs-valuemax?
> 

I think we can set these attributes based on info provided by numberbox.

    
    

    
  
If we want to expose datatype/valuenow/valuemin/valuemax for numberbox then we should have an accessible for numberbox that implements nsIAccessibleValue. Right?

    
    

    
  
> Who wants to use these attributes? 
Any alternative input system -- voice input, on screen keyboards, cell phones, etc.

> Who will provide these attributes excepting us?
Most likely other browsers

> I'm not sure we should expose xs-type/xs-valuemin/xs-valuemax because 
> there are similar ARIA properties.
Actually, we do. We want to map these properties the same way to object attributes whether they come via ARIA, XUL, XForms or HTML 5. Unless there's some problem you know of?

Using niIAccessibleValue for the numberbox as a good idea. Good point.

    
    

    
  
(In reply to comment #6)

> > I'm not sure we should expose xs-type/xs-valuemin/xs-valuemax because 
> > there are similar ARIA properties.
> Actually, we do. We want to map these properties the same way to object
> attributes whether they come via ARIA, XUL, XForms or HTML 5. Unless there's
> some problem you know of?

I have a problem with terms. What is difference between properties and object attributes?

    
    

    
  
(In reply to comment #7)
> (In reply to comment #6)
> 
> > > I'm not sure we should expose xs-type/xs-valuemin/xs-valuemax because 
> > > there are similar ARIA properties.
> > Actually, we do. We want to map these properties the same way to object
> > attributes whether they come via ARIA, XUL, XForms or HTML 5. Unless there's
> > some problem you know of?
> 
> I have a problem with terms. What is difference between properties and object
> attributes?
> 

Ah, do you mean if ARIA property is 'valuemin' then we should not expose 'valuemin' object attribute but we should expose 'xs-valuemin'? I just started to think object attributes is upperset of ARIA properties and there where they are coincide each other then they have the same names. It was wrong point I guess. Is there any documentation which attributes we should expose? And what we should do with 'datatype' attribute we expose now, should we rename it as 'xs-type'?

    
  
Blocks: xula11y

    
    

    
  
> Ah, do you mean if ARIA property is 'valuemin' then we should not expose
> 'valuemin' object attribute but we should expose 'xs-valuemin'? 
Right, it's an idea.

We should only change the name of a DOM attribute if we expose it as accessible object property if there is a good reason. In this case, my reasoning is that if all the data constraint attributes start with "xs-" or some prefix, it will be easier for AT developers to know which ones they are.

Object attributes are purposely not specified anywhere. They're "loosely specified" so that application developers have the flexibility to expose new things. But, as we implement them we should document what we implement. Other vendors will likely follow our lead.


    
    

    
  
Surkov, do you think we should use a prefix like "xs-" for all the datatype-related object attributes?

xs-type, xs-valuemin, etc.?

    
    

    
  
(In reply to comment #10)
> Surkov, do you think we should use a prefix like "xs-" for all the
> datatype-related object attributes?
> 
> xs-type, xs-valuemin, etc.?
> 

I don't mind really. It doesn't make easier to find them because they should know what exactly they search. But however it may prevent to use one and the same name for different attribute by mistake. xs means XML Schema?

    
    

    
  
Right it stands for XML-schema, which is a bad dependency for the name, since the info can come from something else.

So maybe:

value-min, value-type, value-pattern, etc. would be good.

I think it makes it easier for developers to understand, especially once we get a lot of different object attributes.



    
    

    
  
Or even remove the hyphen, which means valuemin and valuemax would still be the same.

So then you'd also have valuepattern, valuetype etc.

    
    

    
  
(In reply to comment #13)
> Or even remove the hyphen, which means valuemin and valuemax would still be the
> same.
> 
> So then you'd also have valuepattern, valuetype etc.
> 

So why do not follow ARIA names? It's lesser things to remember. Btw, what is a value pattern?

    
    

    
  
There aren't ARIA names for everything that we have an object attribute.

For example, you can use aaa:datatype to point to an schema definition, which defines the pattern of A data string. The pattern is a regular expression.

    
    

    
  
(In reply to comment #15)
> There aren't ARIA names for everything that we have an object attribute.

But for those that are defined in ARIA why to use something else?

    
    

    
  
Okay. Most of them don't actually have ARIA equivalents, but are defined via schema definition.

I've updated this doc -- how is that?
http://wiki.mozilla.org/Accessibility/Datatypes

If you'd like something different go ahead and change it and I'll view the diff.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patc2
        — 
          — Splinter Review
      

    


  
1) expose 'valuemin', 'valuemax', 'valuenow' attributes
2) add support for textbox@type="number"

        Attachment #273548 -
        Attachment is obsolete: true

        Attachment #275452 -
        Flags: review?(aaronleventhal)

    
    

    
  
Surkov, I hope youy don't get too annoyed, but I believe I made a mistake :/ There's no reason to have valuenow, valuemin or valuemax as object attributes when there's already nsIAccessibleValue/IAccessibleValue/AtkValue interfaces to get that information.

The other object attributes on that wiki page should still be important -- there's no other way to expose those.

I don't know why I just realized this now. Sorry for any extra work this causes.

    
    

    
  
Ok. We expose 'posinset' e.t.c attributes because there is no groupPosition() in ATK. We don't want to expose 'valuenow' and e.t.c when nsIAccessibleValue is implemented because there are neither IValue interface nor getAttrbiutes() method for mac and os/2. Correct?

    
    

    
  
I'm not worried about Mac right now. When we do I expect that Mac has some kind of known attribute for value, and we'll need to look at it then.

OS/2 has no special a11y API and we'll never be worried about that anyway.

    
    

    
  
Comment on attachment 275452 [details] [diff] [review]
patc2

We don't need to expose valuenow/valuemin/valuemax as object attibutes because IA2/ATK do it.

        Attachment #275452 -
        Flags: review?(aaronleventhal) → review-

    
    

    
  
Alex, do we still want this?

    
    

    
  
(In reply to Marco Zehe (:MarcoZ) from comment #23)
> Alex, do we still want this?

it appears datatype object attribute wasn't picked up by parties (AT or IA2). So I don't think we should anything do here.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: