I'd like to propose an option to make it easier for accessible users to create documents and make it easy for non-accessible users to create accessible documents. It would be a predictive mode that would automatically take actions for a11y users which they would likely want to do next, as well as make some actions that are exclusively mouse driven accessible to them. Here are some of the features that would enabled when accessibility mode was on. 1) After inserting an object (e.g. an image) the description dialog (.uno:ObjectTitleDescription) would automatically open so the user can add a title. (bug 39558) 2) When inserting a shape, the shape is automatically inserted into the document and doesnt require the mouse to draw it. I believe there must be more that could be added to this list and hope people will suggest them.
Hmm, not sure this is the *right* thing to do. Seems that UI implementation that does not lend itself well to supporting Assistive Technology (AT) needs to be adjusted to by default support AT use--and not implement options for it. Obvious issues are exposed not even needing an AT tool, simply attempt to create or edit a document or drawing *without* use of a mouse--take care of those issues by default and you address the majority of accessibility issues. [1] Additionally there is the related need of producing documents (ODF, PDF, SVG) that are fully formatted to support AT tools. =-ref-= 1. the reason this works is that by providing keyboard navigation, most AT tools are aware of the focus change involved and parse that as an accessible event. Labeling and contextual help becomes available. Although there are legitimate issues with the wrong accessible event type being assigned.
Hi, I tend to agree with Vstuart. I think a such behaviour (item 1) should be by default, so that users produce naturally an accessible document. Yes, I'm aware of the fact it's a kind of "forcing" against users, but I think it's also more efficient to get accessible documents, because educational methods is so hard (many people, need to explain how and why, etc). If the productivity suite has dialogs or wizards to require something before inserting some objects, people will make it accessible without even being aware of it. And it's likely a good thing. Letting users choose results they do not, and many docs are not accessible (yes we never know who will use a doc, etc). For the accessibility of the commands (item 2), yes it will be excellent to have capability to automate certain things as shape posjtionning, etc. Also making accessible via menus commands on the toolbar is a quite excellent idea. Finally, I think the background of vstuart's message is the idea of universal design, and I like this. The idea that everybody has the same base accessible regardless its situation, instead of dedicated modes. Because modes need to be maintained, and it may be hard when an app is updated, etc. So I'd agree with 2nd item, but would think the 1st should be by default. Best regards,
(In reply to V Stuart Foote from comment #1) > Hmm, not sure this is the *right* thing to do. Seems that UI implementation > that does not lend itself well to supporting Assistive Technology (AT) needs > to be adjusted to by default support AT use--and not implement options for > it. Similar to how we put the most important features in the context menu to provide easy access to them for mouse users to speed up their workflow, a11y always title inserted objects, so to speed up their workflow we can automatically popup the dialog. (In reply to Jean-Philippe MENGUAL from comment #2) > I tend to agree with Vstuart. I think a such behaviour (item 1) should be by > default, so that users produce naturally an accessible document. Yes, I'm > aware of the fact it's a kind of "forcing" against users, but I think it's > also more efficient to get accessible documents, because educational methods > is so hard (many people, need to explain how and why, etc). If the > productivity suite has dialogs or wizards to require something before > inserting some objects, people will make it accessible without even being > aware of it. And it's likely a good thing. Letting users choose results they > do not, and many docs are not accessible (yes we never know who will use a > doc, etc). The intent is to provide a better workflow for a11y users and not to worsen the workflow for non-a11y users. It wouldnt be good UX for non-a11y users to always get prompted to name an inserted object, as they can see the object in their document.
(In reply to Yousuf Philips (jay) from comment #3) > (In reply to V Stuart Foote from comment #1) > > Hmm, not sure this is the *right* thing to do. Seems that UI implementation > > that does not lend itself well to supporting Assistive Technology (AT) needs > > to be adjusted to by default support AT use--and not implement options for > > it. > > Similar to how we put the most important features in the context menu to > provide easy access to them for mouse users to speed up their workflow, a11y > always title inserted objects, so to speed up their workflow we can > automatically popup the dialog. > @Jay, think we need to rethink that--it is not to support an AT tools workflow, but to produce documents and provide a UI that meet minimal standards for accessibility. Our current defaults do not do that! The UI option should be the reverse--that we produce compliant documents by default, but allow users an optional UI to streamline their workflow but that can produce non-compliant documents unless they add the missing annotation. > (In reply to Jean-Philippe MENGUAL from comment #2) > The intent is to provide a better workflow for a11y users and not to worsen > the workflow for non-a11y users. It wouldnt be good UX for non-a11y users to > always get prompted to name an inserted object, as they can see the object > in their document. Neither the project nor TDF can afford that position--were it true. It is a question of reasonable accommodation--while individual users may elect to produce documents not mindful of supporting accessibility requirements the vast majority of users must prepare compliant documents. Most governmental organizations are obliged to meet the 38 A/AA level WCAG 2.0 success criteria--IMHO the TDF and the project are committed to meet those requirements as they must be. =-ref-= WCAG 2.0--ISO/IEC 40500:2012--success criteria https://www.w3.org/TR/wcag2ict/ and the related W3C ATAG 2.0 https://www.w3.org/TR/ATAG20/ Both the EU and US incorporate by reference the WCAG 2.0 criteria, meaning that to meet statutory requirements LibreOffice UI must meet criteria both in its usser interface as document "authoring tool" and in the documents it creates. Clause 10 & 11 of EN 301 549 http://mandate376.standards.eu/standard United States Access Board Section 508 rules https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/proposed-rule/text-of-the-proposed-rule
(In reply to V Stuart Foote from comment #4) > @Jay, think we need to rethink that--it is not to support an AT tools > workflow, but to produce documents and provide a UI that meet minimal > standards for accessibility. Our current defaults do not do that! The UI > option should be the reverse--that we produce compliant documents by > default, but allow users an optional UI to streamline their workflow but > that can produce non-compliant documents unless they add the missing > annotation. @Stuart: I look forward to reading your bug report that lists what is needed to achieving the minimal standards for accessibility and how we can produce compliant documents by default. But getting back to what this bug report is intended for, its about providing another level of easy for a11y users, even after having an acceptable default accessibility level.
OK, in that context then -- INVALID or WONTFIX, this is a bad idea.
(In reply to V Stuart Foote from comment #6) > OK, in that context then -- INVALID or WONTFIX, this is a bad idea. No that isnt what i meant.