GNOME Bugzilla – Bug 739140
Consider adding subroles
Last modified: 2021-06-10 11:27:30 UTC
Our current roles mainly reflect the type of widget/object rather than the purpose of that widget/object. Knowing the purpose makes it possible for assistive technologies to further refine what events they present and ignore and any alternative navigation they provide. See bug 648259 for some (though not all) use cases. We solved some of the issues by the addition of more AtkRole types. But it would be helpful to have some further means to identify the purpose of a particular object and do so without adding even more AtkRole types. One possibility is the use of subroles, which Apple does. Results from investigation: The following is taken from their roles documentation [1]. I don't think we need all of these -- in fact, I don't think we need most of these, but some would be helpful. I'll comment on which separately. Button subroles: * Close Button * Decrement Arrow * Decrement Page * Full Screen Button * Increment Arrow * Increment Page * Minimize Button * Sort Button * Toolbar Button * Zoom Button Dock item subroles: * Application Dock Item * Dock Extra Dock Item * Document Dock Item * Folder Dock Item * Minimized Window Dock Item * Separator Dock Item * Trash Dock Item * URL Dock Item Image subroles: * Text Attachment Link subroles: * Text Link List subroles: * Content List * Definition List * Process Switcher List Row subroles: * Outline Row * Table Row Slider subroles: * Rating Indicator * Timeline Text field subroles: * Search Field * Secure Text Field Window subroles: * Dialog * Floating Window * Standard Window * System Dialog * System Floating Window From looking through their platform code in WebKit, there is also: Math subroles (to support MathML): * Math Fraction * Math Fenced * Math Subscript Superscript * Math Row * Math Under Over * Math Square Root * Math Root * Math Text * Math Number * Math Identifier * Math Table * Math Table Row * Math Table Cell * Math Fence Operator * Math Separator Operator * Math Operator * Math Multiscript Landmark subroles (to support ARIA landmarks): * Landmark Application * Landmark Banner * Landmark Complementary * Landmark ContentInfo * Landmark Main * Landmark Navigation * Landmark Search [1]https://developer.apple.com/library/mac/documentation/UserExperience/Reference/Accessibility_RoleAttribute_Ref/Role.html
Sorry to be spammy, but I wanted to separate what is versus what Joanie thinks. > Button subroles: > * Close Button > * Decrement Arrow > * Decrement Page > * Full Screen Button > * Increment Arrow > * Increment Page > * Minimize Button > * Sort Button > * Toolbar Button > * Zoom Button Most of those I don't think we need. Some which might be of value: * Toolbar Button (otherwise you have to ascend the accessible hierarchy) * Sort Button (explains -- and suggests Orca should present -- change in non-focused table contents) > Dock item subroles: > * Application Dock Item > * Dock Extra Dock Item > * Document Dock Item > * Folder Dock Item > * Minimized Window Dock Item > * Separator Dock Item > * Trash Dock Item > * URL Dock Item If we turn "Dock item" into "icon", then most of the above apply to anything with an icon panel (Nautilus, web app interface to online storage). I think we do NOT need "Extra", "Minimized Window", or "Separator": The first, I don't even know what it is. The second is something we don't have; but those icons show up in the OS X dock. And we have ATK_ROLE_SEPARATOR for the third. > Image subroles: > * Text Attachment Might be helfpul for mail clients. > Link subroles: > * Text Link Not needed. > List subroles: > * Content List > * Definition List Not needed. Our existing roles cover lists, except for: > * Process Switcher List For us, the Switcher is not a list. But knowing something is a switcher would be helpful. > Row subroles: > * Outline Row > * Table Row Not needed. Our existing roles cover those. > Slider subroles: > * Rating Indicator > * Timeline Rating and timeline would be helpful. > Text field subroles: > * Search Field > * Secure Text Field Search would be helpful. We have ATK_ROLE_PASSWORD_TEXT for the second. > Window subroles: > * Dialog > * Floating Window > * Standard Window > * System Dialog > * System Floating Window We have roles for the window types. So not needed. > Math subroles (to support MathML): > * Math Fraction > * Math Fenced > * Math Subscript Superscript > * Math Row > * Math Under Over > * Math Square Root > * Math Root > * Math Text > * Math Number > * Math Identifier > * Math Table > * Math Table Row > * Math Table Cell > * Math Fence Operator > * Math Separator Operator > * Math Operator > * Math Multiscript I need to look more at the above, but in general, I think we want them. > Landmark subroles (to support ARIA landmarks): > * Landmark Application > * Landmark Banner > * Landmark Complementary > * Landmark ContentInfo > * Landmark Main > * Landmark Navigation > * Landmark Search We want the landmark subroles too. Other stuff I think we want: * MediaControlContainer * MediaPlayButton * MediaPauseButton * MediaNextButton * MediaPreviousButton * MediaSeekButton * MediaMuteButton * MediaVolume * MediaMute * DateTimeField * BusyIndicator * SlideShow
One more thought: Assuming everyone agrees that there is benefit in subroles, the question is how to implement it. We could, of course, add proper API to AtkObject (which would be fine with me). But another option would be to make this something implementors expose via AtkObject's attributes. The disadvantage of going the object-attribute route is that implementors can make stuff up. We explicitly are trying to put a stop to that by deprecating the ability to provide an "extended" role. The advantages are: 1. Those in the extender camp could still extend -- and do so without depriving assistive technologies of all knowledge regarding what the widget/object really is. 2. Really easy to add new subroles as the need comes up. If we decide to do this, we'll need to have really good documentation because I have a need for the roles I cited above. And I want them to appear in a consistent fashion regardless of implementor. In addition, I think we'll want to have both a subrole and a localized subrole. We can localize the official subrole names, but if people start making up their own subroles then it is their job to get them localized.
(In reply to comment #1) > > Text field subroles: > > * Search Field > > * Secure Text Field > > Search would be helpful. We have ATK_ROLE_PASSWORD_TEXT for the second. Looking at the HTML5 input types, there are more that we do not have covered and whose user interaction is sufficiently different from an ordinary input field that Orca and its users would benefit from Orca being able to identify them. Thus some more proposed subroles: * Date and time * Date * Month * Week * Time * Color * Telephone * Email * URL
(In reply to comment #1) > Rating and timeline would be helpful. > > > Text field subroles: > > * Search Field > > * Secure Text Field > > Search would be helpful. We have ATK_ROLE_PASSWORD_TEXT for the second. Note that for the case of PASSWORD_TEXT, there is an discussion about stopping to have specific password related roles, and changing that for a STATE: https://bugzilla.gnome.org/show_bug.cgi?id=668025#c1 Although we don't have a conclusion yet, I'm somewhat biased to that option.
As far as I see, this seems an analysis of what others have, in order to consider to add to ATK or not. But, do you plan to analyse what we have right now? For example, the following roles: ATK_ROLE_PARAGRAPH ATK_ROLE_CAPTION ATK_ROLE_DOCUMENT_TEXT ATK_ROLE_BLOCK_QUOTE etc could be considered as subroles of a TEXT related "parent role". I mention this because one of the advantages I see to add subroles, would be tidy the current list of roles we have, because in several cases, some seem like specializations of other roles. Do you plan to work on that categorization?
(In reply to comment #2) > One more thought: Assuming everyone agrees that there is benefit in subroles, > the question is how to implement it. We could, of course, add proper API to > AtkObject (which would be fine with me). Let's assume for now that we add a specific API for that. Any other option would be a fallback (just in case we need this just right now, or anything else). The straightforward solution would be having something like this: AtkRole atk_object_get_role (AtkObject *accessible) AtkSubrole atk_object_get_sub_role (AtkObject *accessible) And then define a new enum AtkSubrole listing all the possible subroles. The problem with this approach is that there isn't any explicit relation between a role and a subrole. Which subroles are valid for a given role would be only defined using the documentation. But as far as I see (5 min search), that is what Apple does too. So, opinions? Other ideas?
From some chatting in IRC: We might need a new role-related object complete with API. For now, let's call it AtkRoleStuff. Then we could do things like: * atk_object_get_role_stuff * atk_role_stuff_get_role * atk_role_stuff_get_subrole * atk_role_stuff_get_role_name * atk_role_stuff_get_subrole_name * atk_role_stuff_get_localized_role_name * atk_role_stuff_get_localized_subrole_name Not sure if we really need all of the above, but.... One use case we do need to handle is the ability of implementors, and also content creators (digital publishing, educational testing, web app developers, etc.) to provide an end-user-consumable thing to present -- without taking away the actual role and subrole from ATs. Some examples: 1. Role = Section, Subrole = Chapter, thing Orca should speak is not "Chapter", but rather "Canto" because it's Dante's Inferno and that's what the publishing industry wants Orca to say. Orca still wants to know it's a Chapter so that it can provide quick key navigation so the user can press a single key to move from chapter to chapter. 2. Role = Checkbox, thing Orca should speak is not "checkbox" but "slice". This example was raised by someone creating an online educational content related to teaching kids fractions. The exercise was to shade in a portion of what looked like a pie chart to answer a question. And the question was phrased in terms of pizza slices. There were no checkboxes visible. But in order to accomplish the needed accessible toggle functionality and associated state change notifications, the underlying ARIA used checkboxes. Speaking "checkbox" as the user tabs from slice to slice just confuses the kids. But if you take away the role, Orca won't know to present the toggled state because object:state-changed:checked doesn't make sense for a slice -- whatever a slice is....
Other considerations from chatting in IRC: Looks like we might be deprecating atk_object_get_role as it would serve no purpose being covered by the above. Then the question is, should the bridge put in some sort of magic foo to get the RoleStuff and fall back on the old Role? I don't think this is needed. Orca can check for both until everything is fully implemented.
So I don't forget: * image map link (subrole of link) * grid (subrole of table) Also wondering if we want to add a role for shape with subroles for the shape types. In the case of imagemap areas, the area is not exposed as an area but as a link child of the image. But with accessible SVG, org charts, etc....
(In reply to comment #5) > As far as I see, this seems an analysis of what others have, in order to > consider to add to ATK or not. But, do you plan to analyse what we have right > now? > > For example, the following roles: > ATK_ROLE_PARAGRAPH > ATK_ROLE_CAPTION > ATK_ROLE_DOCUMENT_TEXT > ATK_ROLE_BLOCK_QUOTE > etc > > could be considered as subroles of a TEXT related "parent role". > > I mention this because one of the advantages I see to add subroles, would be > tidy the current list of roles we have, because in several cases, some seem > like specializations of other roles. > > Do you plan to work on that categorization? sure.
Categorization is hard. First pass. // ATK_ROLE_ANNOTATION ATK_SUBROLE_ANNOTATION_COMMENT, ATK_SUBROLE_ANNOTATION_DELETION, ATK_SUBROLE_ANNOTATION_ENDNOTE, ATK_SUBROLE_ANNOTATION_INSERTION, ATK_SUBROLE_ANNOTATION_FOOTNOTE, // ATK_ROLE_APPLICATION // ATK_ROLE_BUTTON ATK_SUBROLE_BUTTON_CHECK, ATK_SUBROLE_BUTTON_RADIO, ATK_SUBROLE_BUTTON_SWITCH, ATK_SUBROLE_BUTTON_TOGGLE, ATK_SUBROLE_BUTTON_TRISTATE, ATK_SUBROLE_BUTTON_PUSH, // ATK_ROLE_CONTAINER ATK_SUBROLE_CONTAINER_CALENDAR, ATK_SUBROLE_CONTAINER_CANVAS, ATK_SUBROLE_CONTAINER_FORM, ATK_SUBROLE_CONTAINER_GROUPING, ATK_SUBROLE_CONTAINER_INFO_BAR, ATK_SUBROLE_CONTAINER_INTERNAL_FRAME, ATK_SUBROLE_CONTAINER_MENU_BAR, ATK_SUBROLE_CONTAINER_PANEL, ATK_SUBROLE_CONTAINER_SCROLL_PANE, ATK_SUBROLE_CONTAINER_SPLIT_PANE, ATK_SUBROLE_CONTAINER_STATUS_BAR, ATK_SUBROLE_CONTAINER_SWITCHER, ATK_SUBROLE_CONTAINER_TITLE_BAR, ATK_SUBROLE_CONTAINER_TOOL_BAR, // ATK_ROLE_DOCUMENT ATK_SUBROLE_DOCUMENT_EMAIL, ATK_SUBROLE_DOCUMENT_PRESENTATION, ATK_SUBROLE_DOCUMENT_SPREADSHEET, ATK_SUBROLE_DOCUMENT_TEXT, ATK_SUBROLE_DOCUMENT_WEB, // ATK_ROLE_DOCUMENT_REGION, ATK_SUBROLE_DOCUMENT_REGION_ARTICLE, ATK_SUBROLE_DOCUMENT_REGION_BLOCK_QUOTE, ATK_SUBROLE_DOCUMENT_REGION_CAPTION, ATK_SUBROLE_DOCUMENT_REGION_CHAPTER, ATK_SUBROLE_DOCUMENT_REGION_DEFINITION, ATK_SUBROLE_DOCUMENT_REGION_FOOTER, ATK_SUBROLE_DOCUMENT_REGION_HEADER, ATK_SUBROLE_DOCUMENT_REGION_HEADING, ATK_SUBROLE_DOCUMENT_REGION_PAGE, ATK_SUBROLE_DOCUMENT_REGION_PARAGRAPH, ATK_SUBROLE_DOCUMENT_REGION_SECTION, // ATK_ROLE_GRAPHIC ATK_SUBROLE_GRAPHIC_ANIMATION, ATK_SUBROLE_GRAPHIC_AVATAR, ATK_SUBROLE_GRAPHIC_CHART, ATK_SUBROLE_GRAPHIC_DECORATIVE, ATK_SUBROLE_GRAPHIC_GLYPH, ATK_SUBROLE_GRAPHIC_IMAGE, ATK_SUBROLE_GRAPHIC_ICON, ATK_SUBROLE_GRAPHIC_IMAGEMAP, ATK_SUBROLE_GRAPHIC_LAUNCHER, ATK_SUBROLE_GRAPHIC_MAP, // ATK_ROLE_INFO // better name needed ATK_SUBROLE_INFO_ALERT, ATK_SUBROLE_INFO_LOG, ATK_SUBROLE_INFO_MARQUEE, ATK_SUBROLE_INFO_NOTIFICATION, ATK_SUBROLE_INFO_TOOL_TIP, // ATK_ROLE_TEXT_INPUT ATK_SUBROLE_TEXT_INPUT_COLOR, // for implementations where it's a textfield ATK_SUBROLE_TEXT_INPUT_COMBOBOX, // for the entry in an editable combobox ATK_SUBROLE_TEXT_INPUT_DATE, ATK_SUBROLE_TEXT_INPUT_EMAIL, ATK_SUBROLE_TEXT_INPUT_DATETIME, ATK_SUBROLE_TEXT_INPUT_MONTH, ATK_SUBROLE_TEXT_INPUT_MULTI_LINE, ATK_SUBROLE_TEXT_INPUT_SEARCH, ATK_SUBROLE_TEXT_INPUT_SINGLE_LINE, ATK_SUBROLE_TEXT_INPUT_SPIN_BUTTON, ATK_SUBROLE_TEXT_INPUT_TELEPHONE, ATK_SUBROLE_TEXT_INPUT_WEEK, ATK_SUBROLE_TEXT_INPUT_URL, // ATK_ROLE_LANDMARK ATK_SUBROLE_LANDMARK_APPLICATION, ATK_SUBROLE_LANDMARK_BANNER, ATK_SUBROLE_LANDMARK_COMPLEMENTARY, ATK_SUBROLE_LANDMARK_CONTENT_INFO, ATK_SUBROLE_LANDMARK_MAIN, ATK_SUBROLE_LANDMARK_NAVIGATION, ATK_SUBROLE_LANDMARK_SEARCH, // ATK_ROLE_LINK ATK_SUBROLE_LINK_IMAGEMAP, // ATK_ROLE_LIST ATK_SUBROLE_LIST_COMBO_BOX, ATK_SUBROLE_LIST_DEFINITION, ATK_SUBROLE_LIST_GLOSSARY, ATK_SUBROLE_LIST_ITEMIZED, ATK_SUBROLE_LIST_LAYOUT, ATK_SUBROLE_LIST_MULTI_SELECT, ATK_SUBROLE_LIST_SINGLE_SELECT, ATK_SUBROLE_LIST_TABBED, ATK_SUBROLE_LIST_TABLE_OF_CONTENTS, ATK_SUBROLE_LIST_TREE, // ATK_ROLE_LIST_ITEM ATK_SUBROLE_LIST_ITEM_OPTION, ATK_SUBROLE_LIST_ITEM_SEPARATOR, ATK_SUBROLE_LIST_ITEM_TAB, ATK_SUBROLE_LIST_ITEM_TEXT, ATK_SUBROLE_LIST_ITEM_TERM, ATK_SUBROLE_LIST_ITEM_TREE, ATK_SUBROLE_LIST_ITEM_VALUE, // ATK_ROLE_MATH ATK_SUBROLE_MATH_FRACTION, ATK_SUBROLE_MATH_GROUPING, ATK_SUBROLE_MATH_ROOT, ATK_SUBROLE_MATH_TABLE, ATK_SUBROLE_MATH_TABLE_ROW, ATK_SUBROLE_MATH_TABLE_CELL, ATK_SUBROLE_MATH_TEXT, // applies to strings that aren't special (to Orca) ATK_SUBROLE_MATH_SQUARE_ROOT, ATK_SUBROLE_MATH_SUBSCRIPT_PRE, ATK_SUBROLE_MATH_SUBSCRIPT_POST, ATK_SUBROLE_MATH_SUPERSCRIPT_PRE, ATK_SUBROLE_MATH_SUPERSCRIPT_POST, // ATK_ROLE_MEDIA ATK_SUBROLE_MEDIA_AUDIO, ATK_SUBROLE_MEDIA_VIDEO, // ATK_ROLE_MENU ATK_SUBROLE_MENU_POPUP, // ATK_ROLE_MENU_ITEM ATK_SUBROLE_MENU_ITEM_CHECK, ATK_SUBROLE_MENU_ITEM_POPUP, ATK_SUBROLE_MENU_ITEM_RADIO, ATK_SUBROLE_MENU_ITEM_SEPARATOR, ATK_SUBROLE_MENU_ITEM_SUBMENU, // ATK_ROLE_RANGE ATK_SUBROLE_RANGE_DIAL, ATK_SUBROLE_RANGE_LEVEL_BAR, ATK_SUBROLE_RANGE_METER, ATK_SUBROLE_RANGE_PROGRESS_BAR, ATK_SUBROLE_RANGE_RATING, ATK_SUBROLE_RANGE_RULER, ATK_SUBROLE_BAR_SCROLL_BAR, ATK_SUBROLE_RANGE_SLIDER, ATK_SUBROLE_RANGE_TIMER, // ATK_ROLE_STATIC ATK_SUBROLE_STATIC_IMAGE, ATK_SUBROLE_STATIC_LABEL, ATK_SUBROLE_STATIC_TEXT, // ATK_ROLE_TABLE ATK_SUBROLE_TABLE_DATA, ATK_SUBROLE_TABLE_GRID, ATK_SUBROLE_TABLE_LAYOUT, ATK_SUBROLE_TABLE_TREE, // ATK_ROLE_TABLE_REGION ATK_SUBROLE_TABLE_REGION_CELL, ATK_SUBROLE_TABLE_REGION_ROW, ATK_SUBROLE_TABLE_REGION_COLUMN_HEADER, ATK_SUBROLE_TABLE_REGION_ROW_HEADER, // ATK_ROLE_TERMINAL // ATK_ROLE_WINDOW ATK_SUBROLE_WINDOW_ALERT_DIALOG, ATK_SUBROLE_WINDOW_COLOR_CHOOSER, ATK_SUBROLE_WINDOW_DIALOG, ATK_SUBROLE_WINDOW_FILE_CHOOSER, ATK_SUBROLE_WINDOW_FONT_CHOOSER, ATK_SUBROLE_WINDOW_INPUT_METHOD_CHOOSER, ATK_SUBROLE_WINDOW_MESSAGE_BOX, ATK_SUBROLE_WINDOW_TOP_LEVEL, // ATK_ROLE_NONE ATK_SUBROLE_NONE, ATK_SUBROLE_UNKNOWN,
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of atk, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a ticket at https://gitlab.gnome.org/GNOME/atk/-/issues/ Thank you for your understanding and your help.