Improve accessibility profile functionality
Accessibility profiles have existed in some form for many Ubuntu releases, and provide a relatively easy way for functionality to be enabled for people with various physical disabilities. At the moment, a profile can only be enabled at install time, and only for the first user of an Ubuntu system. In addition, the current profiles are hard coded, and editing them requires a developer to make changes to a package that is only installed on live media. Only Ubuntu is supported at this time, even though there are now more than one GNOME based Ubuntu derivatives.
Blueprint information
- Status:
- Not started
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- Luke Yelavich
- Direction:
- Needs approval
- Assignee:
- Luke Yelavich
- Definition:
- Drafting
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
* A backend profile manager needs to be developed to handle the enabling and disabling of accessibility profiles, and it shouldn't be Ubuntu branded, as longer term it may be beneficial for the upstream desktop environments to adopt this profile manager so that other users running other distros could benefit.
* UI would need to be developed and added somewhere in the settings application for each flavour, and the installer.
* It also may make sense to allow the profile UI to be accessible with a keyboard shortcut, although this doesn't benefit all use cases that the profiles cover.
* Keyboard shortcuts are already used to launch various assistive technologies, it would be nice to be able to ask the user whether they would like to enable a particular accessibility profile associated with that assistive technology to provide a better experience on the system.
* The current profiles on offer in Ubuntu would be used as a starting point, but it should be possible to create custom profiles, and allow profiles to differ per derivative.
* The profile manager and the profile configuration file format needs to support custom gsettings schema paths, as software like Compiz uses custom schema paths heavily for profile and plugin settings.
* A profile configuration structure would probably be something like the following:
- ProfileDir
--- blindness
----- profile.manifest
----- profile.gsettings
* The manifest file would store:
- Unlocalized name
- Localized Name
- Localized Description
- The GSettings key that gets toggled when an assistive technology is turned on or off. (Optional)
* The gsettings file and the manifest would be in key file format, the same format used for .desktop files and gsettings override files.
Notes:
* I (TheMuso) have implemented GSettings support for Orca. It is currently in bugzilla upstream, waiting for review. https:/
Work Items
Work items:
[themuso] Implement backend profile parsing/management library: INPROGRESS
[themuso] Implement command-line utility for profile querying and management: TODO
[themuso] Package the profile management library, and upload to the archive: TODO
[themuso] Get the profile management package into main and seeded: TODO
[themuso] Refactor ubiquity accessibility profile code to use the profile manager library: TODO
[themuso] Investigate options for GUI integration: TODO
