This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 16769 - [AAPI]: blockquote and q mapping
Summary: [AAPI]: blockquote and q mapping
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML a11y APIs (editor: Steve Faulkner, Cynthia Shelly) (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: steve faulkner
QA Contact: HTML a11y API spec bugbot
URL:
Whiteboard:
Keywords: a11y
Depends on:
Blocks:
 
Reported: 2012-04-18 08:42 UTC by alexander surkov
Modified: 2013-03-24 01:28 UTC (History)
5 users (show)

See Also:


Attachments

Description alexander surkov 2012-04-18 08:42:22 UTC
In Firefox blockquote and q mapping are mapped to string role on MSAA (i.e. blockquote and q) are exposed.

Firefox maps them into IA2_ROLE_SECTION/ATK_ROLE_SECTION for blockquote and IA2_ROLE_TEXT_FRAME/ATK_ROLE_TEXT for q. But Neither IA2 nor ATK provides a way to expose semantics of these elements. To fill this gap I'd suggest to expose xml-roles:quote object attribute.

Also these elements have @cite attribute. Spec says (http://dev.w3.org/html5/spec/the-q-element.html#the-q-element):

"If the cite attribute is present, it must be a valid URL potentially surrounded by spaces. To obtain the corresponding citation link, the value of the attribute must be resolved relative to the element. User agents should allow users to follow such citation links."

The suggestion is to expose "showlongdesc" action as Firefox does for img@longdesc (see Mozilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=704449).
Comment 1 Jason Kiss 2012-07-08 02:14:03 UTC
Use of strings "blockquote" and "q" in MSAA VARIANT by Firefox and Chrome now documented:

http://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html#el-13
http://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html#el-114
Comment 2 alexander surkov 2012-09-03 12:13:16 UTC
(In reply to comment #1)
> Use of strings "blockquote" and "q" in MSAA VARIANT by Firefox and Chrome now
> documented:
> 
> http://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html#el-13
> http://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html#el-114

Jason, that 'note' section for firefox and chrome implementations looks as these browsers don't follow the standard. If the spec specifies what browsers do (if they do different things and those things all work) then this would make browsers looking equal. For example,
IE: one thing
Firefox, Chrome: another thing.
Comment 3 Jason Kiss 2013-03-23 23:50:28 UTC
Alex, I'm closing this bug as on 25 September 2012 the HTML to Accessibility APIs guide was updated to remove the individual notes on particular element mappings where Firefox and Chrome pass a string in MSAA VARIANT. 

Additionally, the general note regarding this use of VARIANT by Firefox and Chrome was modified [1] to address your concerns.

Based on your email response at [2], I'm assuming you are comfortable with the updated version of that note. If not, feel free to reopen.


[1] https://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html#other2
[2] http://lists.w3.org/Archives/Public/wai-xtech/2012Sep/0031.html
Comment 4 alexander surkov 2013-03-24 01:28:28 UTC
Thank you Jason. I like the wording.

A correction: that accRole thing is used for pure MSAA clients. Today a role component of HTML elements is exposed by IA2/ATK roles and not standard xml-roles object attribute in case of MSAA/IA2 and ATK APIs.

Btw, the accRole thing might be not especially helpful in case of HTML5, for example all diversity of inputs in HTML5 is exposed as same ROLE_ENTRY.