On Wed, Jan 3, 2018 at 8:51 PM, James Teh <[email protected]> wrote: > Hi Alex, > > If all of these things have semantic value, we really should be creating > new roles for them. However, we probably don't have time to make that > happen given the status of the mappings, so the below answers assume we > don't create new roles. >
We could add new roles if we have to, however it would make IA2 unique, since no other API seems use roles for elements like HTML:q. It is a separate issue, but how do you feel about introducing a basic taxonomies support: for example, roles() method that returns a string containing all comma separated roles, for example, "q,text" for HTML:q element? That would save us from usual torments, we deal with occasionally, whether we should or should not add a new role, which involves IDL changes and not backward compatible. > Note that in IA2, blockquote doesn't have a role either, which is ugly and > needs to be fixed. So, I think we need to have a discussion about creating > a whole bunch of new roles and revising a future version of the mappings to > include them. > > On Wed, Jun 21, 2017 at 4:48 AM, Alexander Surkov < > [email protected]> wrote: > >> * HTML:q [1] >> The spec says [2] to use ROLE_SYSTEM_TEXT which contains >> ROLE_STATIC_TEXT for quotes and ROLE_SYSTEM_TEXT for text itself in >> children. >> > Ideally, I think the MSAA role should be ROLE_SYSTEM_STATICTEXT for the > element and its children here. I've always felt that ROLE_SYSTEM_TEXT was > really meant for navigable text; e.g. <input type="text". > > However, for the element itself, that doesn't fit the convention adopted > elsewhere in the spec... and IA2 clients will ignore the MSAA role in > favour of the IA2 role anyway. So, we should probably leave this as > ROLE_SYSTEM_TEXT for the element itself for now. > For the children, I think they should all be ROLE_SYSTEM_STATICTEXT for > the reason given above. > Note that Gecko exposes text leaves as ROLE_SYSTEM_TEXT, which conflicts > here. In contrast, Chrome uses ROLE_SYSTEM_STATICTEXT (as per my suggestion > to them). > MSAA says that ROLE_SYSTEM_TEXT is "The object represents selectable text that allows edits or is designated as read-only", while ROLE_SYSTEM_STATICTEXT is "The object represents read-only text, such as labels for other controls or instructions in a dialog box. Static text cannot be modified or selected". So it doesn't look like MSAA conforming if we used STATIC_TEXT for text nodes, since they all are selectable as a rule. I think this is a reason why Gecko uses STATIC_TEXT only for things like list item bullets, and TEXT for all other text nodes. I agree though that SYSTEM_TEXT for both HTML:input and a text child of HTML:p also may appear confusing. > * HTML:ruby [3] >> >> The spec suggests [4] to use ROLE_SYSTEM_TEXT. >> > As above, I think this should ideally be STATICTEXT, but I guess we should > leave this as is for now. > Looks good with me. Btw, we also we have more HTML elements like this, for example, HTML:abbr. > >> * @multiple on input@type"file" >> Spec says nothing [6]. Any suggestions on its mapping? >> > There's no "good" mapping at present. > I'm wondering whether we really need to expose this. As far as I know, > there's no (non-a11y) UX pattern for exposing this either apart from > changing the text; e.g. Firefox says "No file selected" or "No files > selected". > My first thought was to abuse STATE_SYSTEM_MULTISELECTABLE. That is not a > great fit because it's meant for containers which can accept multiple > selection, but it kinda sorta works. The question is whether any existing > client will be confused by this. NVDA won't be, but I don't know about > others. > Otherwise, we'd need to create a new state or perhaps an object attribute, > perhaps called multivalue. > But where do we put it? On the button or the text frame? And how does the > client deal with this since there's no indication that it's for a file > chooser? > My feeling on this right now is that we shouldn't expose it specially. > Sounds good with me. As far as I know there's no any indication that the control supports multiple file selection, until the user tries to make multiple selection. > > I also see that <pre> has IA2_ROLE_TEXT_FRAME. The convention seems to be > that TEXT_FRAME is used for inline content, whereas block content uses > SECTION or PARAGRAPH. Chrome already uses PARAGRAPH, but the mappings say > SECTION for ATK. My initial feeling was SECTION. > SECTION seems like a good match for this one. > > Jamie > >
_______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
