Introduction
Accessibility 101
● Equal access to software & information for all users
● Modified or alternative interaction and presentation
Why?
● Right thing to do for us and for our users
● Required to fulfill accessibility guidelines
● It increases your user base
“If you’re not accessible, you lose sales and
reputation”
Marco Zehe, accessibility developer
http://www.marcozehe.de/2012/01/16/if-youre-not-accessible-you-lose-sales-and-reputation/
GNOME 3.X
GNOME 3.2
● Accessibility was still work in progress
● Improvements at the low level
● Accessibility bugs in core applications still present
● Accessibility team small, but regrouping
● Fallback mode was usable, GNOME-Shell not
● Roadmap: Good progress on the 3.0 goals
ATK/AT-SPI2 Hackfest
Photo by Mario Sánchez (License CC BY-SA 2.0)
ATK/AT-SPI2 Hackfest 2012
● Cross-desktop hackfest
● Augmented, consistently-implemented accessibility
● Best practices guide
● Stop to use the bridge as a module/plugin
● Debate/prioritize tasks
● Defined the work to be done for following releases
GNOME 3.4
● First one that Orca users could use GNOME Shell● Orca users reporting bugs
● Orca noticeable more performant
● Magnifier configuration dialog added
GNOME 3.4
● Team still small, but stable
● Roadmap● Performance improvement
● ATK support improved on GNOME-Shell and toolkits
Demo
GNOME 3.6
● Brightness, contrast and inversion
● Focus and caret tracking in GNOME-Shell Magnifier
● Accessibility always on
GNOME 3.6
● Team remains small, but high motivation
● Roadmap: ● Augmented accessibility
● BUT: continued lack of ATs for users with other disabilities
● BUT: some core apps still lack proper support
Magnifier features
Accessibility always on
● Was a setting change, became a library
● Not an add-on but an add-in
● For users: It JustWorks(tm)
● For developers:
● App accessibility gets tested by everyone
● Dragons ahead
● Start testing NOW!
GNOME 3.X: What we need to succeed
● No significant core changes
● Continued present investment in accessibility
● Additional investment:● Fix current accessibility bugs in core apps
● Prevent future accessibility regressions
● Create and/or port tools for users with other disabilities
GUADEC 2012 - A11yCamp
Photo by Alberto García (License CC BY-SA 2.0)
GUADEC 2012 - A11yCamp
● Two day unconference, but with some agenda
● Day1: mostly cross team collaboration
● Day2: mostly accessibility team work
● Regardless of your schedule, show up!
● Where and when?
● Room 2.0a
● Jul 30th (Monday) and Jul 31th (Tuesday)
Relationship with the community
Old times
● Usual suspects: just a bunch of people were doing
accessibility work
● Usual suspects2: just a bunch of people were taking
care of accessibility status
● Accessibility team was like the “accessibility police”
Lately: Awareness
● Toolkits/module maintainers not only reviewing,
they are also providing accessibility related code
● Interest to know how to report accessibility bugs
● Accessibility took into account since the early
stages of new features and designs
Poster boy
Friends of GNOME
“Help make 2012 the Year of Accessibility for
GNOME!”
THANKS!!
A summary?
Conclusions
● We have a running GNOME accessibility framework
● We have users and a motivated team
● All the GNOME community involved
● BUT: Not enough ATs, small team
Contact and links
● gnome-accessibility-list at gnome.org
● gnome-accessibility-devel at gnome.org
● https://live.gnome.org/Accessibility
