513664 - both frame and DOM information should be used to create an accessible for HTML content

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[alexander :surkov (:asurkov)]

The meantime the code is oriented mostly on frame information when we create HTML accessibles. However we use DOM information in some cases. We need to combine these cases. For example,

<ul style="display: table">
  <li style="display: table-row">
    <a style="display: table-cell" href="">link</a>
  </li>
</ul>

Based on frame information we'll loose anchor features, based on DOM information we'll lose table stuffs. We need to find a way to combine these approaches. One way I can see is use aggregation when one accessible will aggregate another one. However we should define what will be more important in the case when functionality is overlapped.

Comment 1

[alexander :surkov (:asurkov)]

We should decide what's more important, DOM or frames information? However cases from bug 439205 and bug 441241 makes me thing roles are in contradiction only. So it should be main question what role should we use? 

For example, should it be ROLE_TABLE or ROLE_LIST in the case of bug 439205? The example from bug 441241 has a list styled as a table. It looks like it's more important to expose it as a list (especially it makes sense to expose HTML:a element as ROLE_LINK however it is styled as table cell). But I keep in mind the case when DHTML authors could create ARIA grid/treegrid based on HTML div styled as a table. It's more important information is table interface in this case I guess.

Probably it's worth to reserve new object attribute to expose secondary role like "secondary-role" or something. In this case we could expose role from markup as primary role and expose role from frame in object attribute. How does it sounds?

Comment 2

[alexander :surkov (:asurkov)]

James, your feedback is appreciated as well.

Comment 3

[alexander :surkov (:asurkov)]

bug 494807 might contradict with the idea

Comment 4

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to comment #0)
> The meantime the code is oriented mostly on frame information when we create
> HTML accessibles. However we use DOM information in some cases. We need to
> combine these cases. For example,
> 
> <ul style="display: table">
>   <li style="display: table-row">
>     <a style="display: table-cell" href="">link</a>
>   </li>
> </ul>
> 
> Based on frame information we'll loose anchor features, based on DOM
> information we'll lose table stuffs. We need to find a way to combine these
> approaches. One way I can see is use aggregation when one accessible will
> aggregate another one. However we should define what will be more important in
> the case when functionality is overlapped.

Is the idea here to walk DOM nodes, and where necessary, have accessible objects built from these DOM nodes indicate they have children that require frame walking?

Comment 5

[alexander :surkov (:asurkov)]

(In reply to comment #4)

> Is the idea here to walk DOM nodes, and where necessary, have accessible
> objects built from these DOM nodes indicate they have children that require
> frame walking?

iirc no. But primary goal is we should decide how we want to deal with these cases.

Comment 6

[David Bolter [:davidb] (NeedInfo me for attention)]

Alexander can you explain what you mean by aggregation using an example?

Comment 7

[alexander :surkov (:asurkov)]

(In reply to comment #6)
> Alexander can you explain what you mean by aggregation using an example?

I guess, when the object appears as a member. The object redirect calls to methods of the aggregated object. Something like.

But as I said probably we need to do nothing (comment #3). We need to consider possible cases and decide should the exposed accessible object combine characteristics of many accessible objects.