Created attachment 102531 [details] Accessible event listener, listens to "focused" events and outputs name Placeholder names like "Frame1" for accessible objects are not useful, and imply additional work for people implementing client applications like screen readers, which should deliberately ignore them to avoid flooding the user with undesired information. An example of this issue are floating text frames, but probably there are more. To reproduce it: * Run the attached event listener * Create a Writer document, insert -> frame, accept * The frame should be focused, otherwise click on it to focus * The event listener will output: "object name: Frame1"
Hmm, are we expected to download and run an executable that we know nothing about? Is this program also available elsewhere? Which OS does it run on? Are there any alternative ways or tools to check this issue? And what is the effect of not having any names? Do AT (as opposed to accessible event listeners) still report the presence of the frame or do they use the absence of a name as an unwritten convention for objects that don't need to be reported (like empty alt attributes on images in HTML4.x and XHTML 1.x)? Anyway, the current behaviour is that LibreOffice always fills in the frame's name (attribute draw:name); when you delete the name and save the file, then reopen the frame options, you will find that LibreOffice has filled in a name. Is there a better way of dealing with this issue than removing the placeholder names? I am thinking specifically of prompting the user to provide a meaningful name when inserting a frame. This would also be useful for many other types of objects.
(In reply to comment #1) > Hmm, are we expected to download and run an executable that we know nothing > about? Is this program also available elsewhere? Which OS does it run on? > Are there any alternative ways or tools to check this issue? > The program is a Python script, it's plain text and you can read the code to check it's not doing nasty things :) It uses pyatspi library so it's supposed to work only in Linux machines. You can also check this using any software that allows browsing the objects exposed by the accessibility API, like Accerciser. I'm attaching a screenshot.
Created attachment 102613 [details] Issue exposed in Accerciser
(In reply to comment #1) > And what is the effect of not having any names? Do AT (as opposed to > accessible event listeners) still report the presence of the frame or do > they use the absence of a name as an unwritten convention for objects that > don't need to be reported (like empty alt attributes on images in HTML4.x > and XHTML 1.x)? > I've checked what Orca does, it says "Frame1 text frame activated" when I focus it, as you can see the role already tells us we are dealing with a text frame. I don't think it ignores objects with empty names, as a matter of fact most objects like paragraphs don't have it. > Anyway, the current behaviour is that LibreOffice always fills in the > frame's name (attribute draw:name); when you delete the name and save the > file, then reopen the frame options, you will find that LibreOffice has > filled in a name. > That's right. As additional info, at right click -> description you can enter a title that will be used as the accessible name of the object, ignoring the name found at right click -> frame -> options. > Is there a better way of dealing with this issue than removing the > placeholder names? I am thinking specifically of prompting the user to > provide a meaningful name when inserting a frame. This would also be useful > for many other types of objects. The description dialog would be a great candidate for this but I fear that prompting the user for a title every time a frame is inserted would be too intrusive.
(In reply to Christophe Strobbe from comment #1) > Anyway, the current behaviour is that LibreOffice always fills in the > frame's name (attribute draw:name); when you delete the name and save the > file, then reopen the frame options, you will find that LibreOffice has > filled in a name. > > Is there a better way of dealing with this issue than removing the > placeholder names? I am thinking specifically of prompting the user to > provide a meaningful name when inserting a frame. This would also be useful > for many other types of objects. Sounds like a UI/UX discussion about best way to improve a11y, so Status -> NEW Component -> ux-advise Severity -> enhancement
(In reply to Jacobo Aragunde Pérez from comment #4) > ... As additional info, at right click -> description you can > enter a title that will be used as the accessible name of the object, > ignoring the name found at right click -> frame -> options. How about changing the behavior so it never falls back to presenting the name of object, but only use the information in title and description? If I'm not mistaken frames needs a unique name. Also that name is among other things useful for features of the navigator.
Migrating Whiteboard tags to Keywords: (a11y -> accessibility)
It should be so interesting to have a real title about the content of the frame for deciding if we want to see the content or not.
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
an issue for all AT tools, adjusting the blocks meta
> * Run the attached event listener > * Create a Writer document, insert -> frame, accept > * The frame should be focused, otherwise click on it to focus > * The event listener will output: "object name: Frame1" It isnt a placeholder name as a user can change this automatically generated name/id with a different one in the options tab of the frame dialog, so i dont see a problem here. But even if a placeholder name was assigned to an object, it is used as a means of differentiating multiple objects of the same kind, and this primarily benefits a11y but also navigator users.
Following comment 11 we should resolve the request as WF.