Closed Bug 996821 Opened 10 years ago Closed 10 years ago

HTML semantic elements should always get an accessible, despite styling

Categories

(Core :: Disability Access APIs, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla31

People

(Reporter: eeejay, Assigned: eeejay)

Details

Attachments

(1 file)

If a semantic element has a style of overflow that is not visible, the frame type is a ScrollFrame. And thus, gets no accessible type via nsIFrame.AccessibleType().

We need to use the tag name to force the creation of an accessible for semantic tags that are obviously useful to ATs.
can you list elements that needs to have an accessible by tag name
(In reply to alexander :surkov from comment #1)
> can you list elements that needs to have an accessible by tag name

section, article, nav, footer, header, aside. There may be more, we might need a better solution here than to adding names to a list. Don't know..
Attachment #8407093 - Flags: review?(surkov.alexander)
(In reply to Eitan Isaacson [:eeejay] from comment #2)
> (In reply to alexander :surkov from comment #1)
> > can you list elements that needs to have an accessible by tag name
> 
> section, article, nav, footer, header, aside.

ok, I didn't know you have a patch :)

> There may be more, we might
> need a better solution here than to adding names to a list. Don't know..

agree, we do that from time to time
(In reply to Eitan Isaacson [:eeejay] from comment #0)
> If a semantic element has a style of overflow that is not visible, the frame
> type is a ScrollFrame. And thus, gets no accessible type via
> nsIFrame.AccessibleType().

I guess you mean that it is not display: visible, but it _is_ visible by being display: overflow or whatever?

If its actually not being rendered I tend to think it shouldn't be accessible.
(In reply to Trevor Saunders (:tbsaunde) from comment #5)
> If its actually not being rendered I tend to think it shouldn't be
> accessible.
Very much agreed.
(In reply to Trevor Saunders (:tbsaunde) from comment #5)
> (In reply to Eitan Isaacson [:eeejay] from comment #0)
> > If a semantic element has a style of overflow that is not visible, the frame
> > type is a ScrollFrame. And thus, gets no accessible type via
> > nsIFrame.AccessibleType().
> 
> I guess you mean that it is not display: visible, but it _is_ visible by
> being display: overflow or whatever?
> 

Don't know what you mean by "display: visible;" I don't think that is a thing. Neither is "display: overflow".

> If its actually not being rendered I tend to think it shouldn't be
> accessible.

overflow: hidden basically means that child content should be clipped by the bounds of the parent. It doesn't mean it is invisible. So if you have a div with a styled width and height of 200px, and it has a child div that is 400px, you will only see the upper left 200px. The default style for these type of elements, afaik, is 'visible', which means that the child element won't get clipped, and you will get all 400px of it.

I am not familiar with the layout code too much, but apparently when the overflow property is changed, the frame type turns into a ScrollFrame and doesn't give a valid AccessibleType.
(In reply to Trevor Saunders (:tbsaunde) from comment #5)
> (In reply to Eitan Isaacson [:eeejay] from comment #0)
> > If a semantic element has a style of overflow that is not visible, the frame
> > type is a ScrollFrame. And thus, gets no accessible type via
> > nsIFrame.AccessibleType().
> 
> I guess you mean that it is not display: visible, but it _is_ visible by
> being display: overflow or whatever?

I believe Eitan meant something like no scrollbars but still scrollable. As long as we have frame then it's something rendered (at least in most cases).
(In reply to Eitan Isaacson [:eeejay] from comment #7)
> (In reply to Trevor Saunders (:tbsaunde) from comment #5)
> > (In reply to Eitan Isaacson [:eeejay] from comment #0)
> > > If a semantic element has a style of overflow that is not visible, the frame
> > > type is a ScrollFrame. And thus, gets no accessible type via
> > > nsIFrame.AccessibleType().
> > 
> > I guess you mean that it is not display: visible, but it _is_ visible by
> > being display: overflow or whatever?
> > 
> 
> Don't know what you mean by "display: visible;" I don't think that is a
> thing. Neither is "display: overflow".

I guess I was thinking about overflow: hidden, I don't make a point of remembering how css works

(In reply to alexander :surkov from comment #8)
> (In reply to Trevor Saunders (:tbsaunde) from comment #5)
> > (In reply to Eitan Isaacson [:eeejay] from comment #0)
> > > If a semantic element has a style of overflow that is not visible, the frame
> > > type is a ScrollFrame. And thus, gets no accessible type via
> > > nsIFrame.AccessibleType().
> > 
> > I guess you mean that it is not display: visible, but it _is_ visible by
> > being display: overflow or whatever?
> 
> I believe Eitan meant something like no scrollbars but still scrollable. As
> long as we have frame then it's something rendered (at least in most cases).

I thought visiblity: hidden got a frame but wasn't visible?
(In reply to Trevor Saunders (:tbsaunde) from comment #9)

> I thought visiblity: hidden got a frame but wasn't visible?

that's right but it's very special case. It's not a case here.

The whole point of the bug as I understand it is when you apply certain styles to HTML elements (that don't affect on element visibility) then they loose their accessibles.
Comment on attachment 8407093 [details] [diff] [review]
Force semantic HTML elements to have accessible objects.

Review of attachment 8407093 [details] [diff] [review]:
-----------------------------------------------------------------

::: accessible/tests/mochitest/role/test_general.html
@@ +137,5 @@
>    <section id="section">a section</section>
>  
> +  <section style="overflow: hidden;" id="section_overflow">
> +    <nav style="overflow: hidden;"
> +            id="nav_overflow">overflow nav</nav>

nit: pls fix indentation
Attachment #8407093 - Flags: review?(surkov.alexander) → review+
https://hg.mozilla.org/mozilla-central/rev/d1ed266256d3
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
You need to log in before you can comment on or make changes to this bug.