Development/Accessibility: Difference between revisions

    From The Document Foundation Wiki
    No edit summary
    (use syntaxhighlight)
    Line 5: Line 5:
    __TOC__
    __TOC__


    ==Enable accessibility support==
    == Enable accessibility support ==


    First of all, don't forget to compile the accessibility (from now on, a11y) support in LibreOffice:
    First of all, don't forget to compile the accessibility (from now on, a11y) support in LibreOffice:
    Line 15: Line 15:
       gsettings set org.gnome.desktop.interface toolkit-accessibility true
       gsettings set org.gnome.desktop.interface toolkit-accessibility true


    ==Script to read a11y events==
    == Script to read a11y events ==


    With the following small python script you will be able to log all the a11y events happening in your system:
    With the following small python script you will be able to log all the a11y events happening in your system:


    <pre>
    <source lang="python">
    #!/usr/bin/python
    #!/usr/bin/python


    Line 46: Line 46:
    pyatspi.Registry.registerEventListener(onFocused, "object:")
    pyatspi.Registry.registerEventListener(onFocused, "object:")
    pyatspi.Registry.start()
    pyatspi.Registry.start()
    </pre>
    </source>


    ==Accerciser==
    == Accerciser ==


    Accerciser is a software to check if an application is providing correct information to assistive technologies and automated testing frameworks. It's available in most distros, just:
    Accerciser is a software to check if an application is providing correct information to assistive technologies and automated testing frameworks. It's available in most distros, just:
    Line 59: Line 59:
    Accerciser is good to browse the accessibility tree or to do some quick queries with its python console, but the event monitor is a bit buggy; to debug events it's better to use the script attached in the previous section.
    Accerciser is good to browse the accessibility tree or to do some quick queries with its python console, but the event monitor is a bit buggy; to debug events it's better to use the script attached in the previous section.


    ==Debugging a11y==
    == Debugging a11y ==


    Two basic points to make applications accessible for visually impaired:
    Two basic points to make applications accessible for visually impaired:
    Line 69: Line 69:
    It may be possible that you can reach some UI element with the keyboard but the corresponding a11y event is not being sent. You can use accerciser to read these events and check if the transitions are being properly informed to a11y-enabling technologies, like a screen reader. Use the "Event monitor" tab, enable "Events monitoring" and "focus" type. Now navigate through LibO window with your keyboard and check that the events are being reported when you change the focus.
    It may be possible that you can reach some UI element with the keyboard but the corresponding a11y event is not being sent. You can use accerciser to read these events and check if the transitions are being properly informed to a11y-enabling technologies, like a screen reader. Use the "Event monitor" tab, enable "Events monitoring" and "focus" type. Now navigate through LibO window with your keyboard and check that the events are being reported when you change the focus.


    ==Reporting an a11y bug==
    == Reporting an a11y bug ==


    If it's related to events, it's a good idea that you attach a tuned version of the listener script that prints only the relevant events and attributes for that bug.
    If it's related to events, it's a good idea that you attach a tuned version of the listener script that prints only the relevant events and attributes for that bug.


    [[Category:Development]]
    [[Category:Development]]

    Revision as of 08:36, 16 June 2014

    Enable accessibility support

    First of all, don't forget to compile the accessibility (from now on, a11y) support in LibreOffice:

      make accessibility
    

    Before running LibreOffice run this command to enable a11y in the GNOME toolkit so the program knows that it should start sending events:

      gsettings set org.gnome.desktop.interface toolkit-accessibility true
    

    Script to read a11y events

    With the following small python script you will be able to log all the a11y events happening in your system:

    #!/usr/bin/python
    
    import pyatspi
    
    def onFocused(e):
        try:
            if e.host_application.name != "soffice":
                return
        except:
            return
    
        print(e)
    
    def onKey(e):
        if e.type == pyatspi.KEY_PRESSED_EVENT:
            eType = "PRESSED"
        else:
            eType = "RELEASED"
        print("%s: %s" % (eType, e.event_string))
    
    pyatspi.Registry.registerKeystrokeListener(
        onKey,
        mask=range(128),
        kind=(pyatspi.KEY_PRESSED_EVENT, pyatspi.KEY_RELEASED_EVENT))
    pyatspi.Registry.registerEventListener(onFocused, "object:")
    pyatspi.Registry.start()

    Accerciser

    Accerciser is a software to check if an application is providing correct information to assistive technologies and automated testing frameworks. It's available in most distros, just:

      yum install accerciser
    

    or

      apt-get install accerciser
    

    Accerciser is good to browse the accessibility tree or to do some quick queries with its python console, but the event monitor is a bit buggy; to debug events it's better to use the script attached in the previous section.

    Debugging a11y

    Two basic points to make applications accessible for visually impaired:

    • Keyboard navigation
    • Events

    There is one trivial way to detect the first kind of a11y bugs: just try to use the application without your mouse, only with keyboard commands (arrows, tabs). If you can't reach every place in the application there's definitely something wrong.

    It may be possible that you can reach some UI element with the keyboard but the corresponding a11y event is not being sent. You can use accerciser to read these events and check if the transitions are being properly informed to a11y-enabling technologies, like a screen reader. Use the "Event monitor" tab, enable "Events monitoring" and "focus" type. Now navigate through LibO window with your keyboard and check that the events are being reported when you change the focus.

    Reporting an a11y bug

    If it's related to events, it's a good idea that you attach a tuned version of the listener script that prints only the relevant events and attributes for that bug.