Closed Bug 982125 Opened 10 years ago Closed 4 years ago

make HTML5 <mark> accessible

Categories

(Core :: Disability Access APIs, defect)

x86_64
Windows 8.1
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla72
Tracking Status
firefox72 --- fixed

People

(Reporter: faulkner.steve, Assigned: MarcoZ)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

unsure exactly how but be good to expose something via acc API to indicate marked text
http://www.w3.org/html/wg/drafts/html/master/text-level-semantics.html#the-mark-element
I'd say it makes sense to expose elements like HTML mark, strong, em and others as text attributes to expose their semantics to AT (in contrast to as we do that now: expose them as bunch of style text attributes).

Jamie, do you ever need to be aware of these elements presence?
Related NVDA issue ticket: http://community.nvda-project.org/ticket/4247

We've had a request to support this in NVDA. It's a bit controversial because even though strong has semantic meaning where bold doesn't, most people just think of it as bold anyway and bold kind of has semantic meaning to most people anyway. However, I do think that mark is more semantically important than strong, and I don't think we should expect users to understand colour changes. Therefore, I'm leaning towards semantically indicating mark but not strong or em.
I'm fine to go with mark only for now, it's fresh and relatively new and hopefully the community is able to prevent it when it's used for styling :)
(In reply to alexander :surkov from comment #3)
> I'm fine to go with mark only for now, it's fresh and relatively new and
> hopefully the community is able to prevent it when it's used for styling :)

Follwoing up on this as nothing appears to have happened :-)
Have updated implementation info for <mark> for review
(In reply to steve faulkner from comment #5)
> Have updated implementation info for <mark> for review

and the link is...
http://w3c.github.io/aria/html-aam/html-aam.html#el-mark
(In reply to steve faulkner from comment #6)
> (In reply to steve faulkner from comment #5)
> > Have updated implementation info for <mark> for review
> 
> and the link is...
> http://w3c.github.io/aria/html-aam/html-aam.html#el-mark

I have to give some thought to what the support in Orca will look like, but the mapping you've provided makes sense for ATK/AT-SPI2. Thanks!
Attached patch Patch (obsolete) — Splinter Review
For the text attribute test change, I get the following entry with a test failure:

2536 INFO TEST-PASS | chrome://mochitests/content/a11y/accessible/tests/mochitest/elm/test_HTMLSpec.html | Wrong start offset for [xpconnect wrapped (nsISupports, nsIAccessible, nsIAccessibleText)] at offset 0 
2537 INFO TEST-PASS | chrome://mochitests/content/a11y/accessible/tests/mochitest/elm/test_HTMLSpec.html | Wrong end offset for [xpconnect wrapped (nsISupports, nsIAccessible, nsIAccessibleText)] at offset 0 
2538 INFO TEST-UNEXPECTED-FAIL | chrome://mochitests/content/a11y/accessible/tests/mochitest/elm/test_HTMLSpec.html | There is no expected attribute 'background-color'  for [xpconnect wrapped (nsISupports, nsIAccessible, nsIAccessibleText)] at offset 0 - expected PASS
2539 INFO TEST-PASS | chrome://mochitests/content/a11y/accessible/tests/mochitest/elm/test_HTMLSpec.html | Attribute 'background-color' has wrong value for [xpconnect wrapped (nsISupports, nsIAccessible, nsIAccessibleText)] at offset 0 

Alex, do you have any idea what's wrong, why this fails on the attribute's presence, but then checks the background color correctly?
Assignee: nobody → mzehe
Status: NEW → ASSIGNED
Attachment #8614689 - Flags: review?(surkov.alexander)
(In reply to Joanmarie Diggs from comment #7)
> (In reply to steve faulkner from comment #6)
> > (In reply to steve faulkner from comment #5)
> > > Have updated implementation info for <mark> for review
> > 
> > and the link is...
> > http://w3c.github.io/aria/html-aam/html-aam.html#el-mark
> 
> I have to give some thought to what the support in Orca will look like, but
> the mapping you've provided makes sense for ATK/AT-SPI2. Thanks!

Do we have to have an accessible object for it. Wouldn't it be enough to expose 'mark:true' text attribute like we do for HTML sub and sup elements?
(In reply to Marco Zehe (:MarcoZ) from comment #8)

> 2539 INFO TEST-PASS |
> chrome://mochitests/content/a11y/accessible/tests/mochitest/elm/
> test_HTMLSpec.html | Attribute 'background-color' has wrong value for
> [xpconnect wrapped (nsISupports, nsIAccessible, nsIAccessibleText)] at
> offset 0 
> 
> Alex, do you have any idea what's wrong, why this fails on the attribute's
> presence, but then checks the background color correctly?

I think this color is default for the mark element and thus it's not exposed at 0 offset.
Comment on attachment 8614689 [details] [diff] [review]
Patch

I'm not sure if we have to have accessible object for the mark element, so cancelling review for now.
Attachment #8614689 - Flags: review?(surkov.alexander)
any update on this?
(In reply to steve faulkner from comment #12)
> any update on this?

Steve, do you have ideas on comment #9 (#9, #9, #9 ;) )?
Spec says to map to xml-roles:mark
Comment on attachment 8614689 [details] [diff] [review]
Patch

Taking another stab at this with the updated spec.
Attachment #8614689 - Attachment is obsolete: true

Mark the html:mark element to role_text, make sure we expose the roleDescription on Mac, and adjust the test so it tests that the attributes don't pick up any unexpected color for this particular element. So, the background attribute is empty when there is no unexpected, non-default background color.

Pushed by mzehe@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4d4efd40bafa
make HTML5 <mark> accessible, r=Jamie
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla72
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: