982125 - make HTML5 <mark> accessible

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[steve faulkner]

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

Comment 1

[alexander :surkov (:asurkov)]

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?

Comment 2

[James Teh [:Jamie]]

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.

Comment 3

[alexander :surkov (:asurkov)]

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 :)

Comment 4

[steve faulkner]

(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 :-)

Comment 5

[steve faulkner]

Have updated implementation info for <mark> for review

Comment 6

[steve faulkner]

(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

Comment 7

[Joanmarie Diggs]

(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!

Comment 8

[Marco Zehe (:MarcoZ)]

Attachment: Patch

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?

Comment 9

[alexander :surkov (:asurkov)]

(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?

Comment 10

[alexander :surkov (:asurkov)]

(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 11

[alexander :surkov (:asurkov)]

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.

Comment 12

[steve faulkner]

any update on this?

Comment 13

[alexander :surkov (:asurkov)]

(In reply to steve faulkner from comment #12)
> any update on this?

Steve, do you have ideas on comment #9 (#9, #9, #9 ;) )?

Comment 14

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

Spec says to map to xml-roles:mark

Comment 15

[Marco Zehe (:MarcoZ)]

Comment on attachment 8614689 [details] [diff] [review]
Patch

Taking another stab at this with the updated spec.

Comment 16

[Marco Zehe (:MarcoZ)]

Attachment: Bug 982125 - make HTML5 <mark> accessible, r=Jamie

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.

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4d4efd40bafa
make HTML5 <mark> accessible, r=Jamie

Comment 18

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/4d4efd40bafa