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)
Core
Disability Access APIs
Tracking
()
RESOLVED
FIXED
mozilla31
People
(Reporter: eeejay, Assigned: eeejay)
Details
Attachments
(1 file)
3.61 KB,
patch
|
surkov
:
review+
|
Details | Diff | Splinter Review |
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.
Comment 1•10 years ago
|
||
can you list elements that needs to have an accessible by tag name
Assignee | ||
Comment 2•10 years ago
|
||
(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..
Assignee | ||
Comment 3•10 years ago
|
||
Attachment #8407093 -
Flags: review?(surkov.alexander)
Comment 4•10 years ago
|
||
(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
Comment 5•10 years ago
|
||
(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.
Comment 6•10 years ago
|
||
(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.
Assignee | ||
Comment 7•10 years ago
|
||
(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.
Comment 8•10 years ago
|
||
(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).
Comment 9•10 years ago
|
||
(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?
Comment 10•10 years ago
|
||
(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 11•10 years ago
|
||
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+
Assignee | ||
Comment 12•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/fceba10dc04b
Assignee: nobody → eitan
Comment 13•10 years ago
|
||
Something in your push was causing mochitest-a11y failures. Backed out. https://hg.mozilla.org/integration/mozilla-inbound/rev/18224f0cc4dd https://tbpl.mozilla.org/php/getParsedLog.php?id=37971356&tree=Mozilla-Inbound
Assignee | ||
Comment 14•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/d1ed266256d3 Sorry, small glitch in the mochitest.
Comment 15•10 years ago
|
||
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.
Description
•