= WebKit Accessibility Performance =
''by Nan Wang''

- Problems
    - “Busy” text in this state entire web page is unresponsive
    - Heavy JS with VoiceOver, can increase CPU utilization (near 100%)
    - VoiceOver indicator can have a wrong indicator, may indicate wrong activation point (no click event)
- WebKit Accessibility Overview
    - Accessibility Flow
    - VoiceOver example on iOS
        - User gasps on the screen at (x, y)
        - VoiceOver hit-tests on the web page
        - WebCore creates AX tree
        - VoiceOver visits the AX node
        - VoiceOver announces the element
    - Why an AX tree?
        - Imagine a web form, several form elements
        - From AX API, less info, less nodes
    - Build Accessibility Tree
        - DOM Tree & Style Sheets > Render Tree > Layout > Accessibility Tree
    - Accessibility in WebCore
        - Lives in WebProcess
- Current Challenges
    - Accessibility Tree Generation
        - constant accessibility tree validation
        - Possible re-layout
        - Slow performance
    - Many IPC calls
        - Accessibility frame retrieval
            - Sometimes retrieves coordinates for frames over and over
    - Sandboxes Web Process
        - Limitations for the system Accessibility API
        - Assistive tech are accessing the web process
        - Other browsers have different approaches
- Solutions
    - Unblock the Main Thread
        - Reduce DOM interaction
            - Average attribute fetching time is 0.05 ms
            - On macOS constantly fetching, could be huge impact on main thread blocking
            - 10x speedup with caching
        - Define Tree Generation Timing
            - Reduce accessibility tree validations
                - 2000 updateBackingStore() calls when a user taps on an element on iOS
                - 0.02ms avg
                - 0.2 ms when a re-layout is triggered
        - Reduce IPC Calls
            - 0.2 ms when retrieving a frame on an iPhone 8 Plus
            - 20x speedup with frame caching
    - Conclusion: Cache!
        - Need to be careful to keep physical footprint low
    - Static Accessibility Trees
        - Store Accessibility Information in some sort of data structure
        - class AccessibilityStaticObject proposal
        - A lot of possible attributes
            - 50 ARIA attributes
            - 90 Attributes exposed on iOS (including ARIA)
            - More on macOS
        - Storing all values could be wasteful
        - Store a Compact Data Structure
        - About 20 attributes for each major data type
            - Use HashMap?
        - Accessibility Tree Generation
            - Class to wrap a one-time snapshot of the accessibility tree up front
            - `class AccessibilityStaticObject`
        - Incremental Tree Updates
            - Class to represent an atomic change to an AccessibilityTree
            - `class AccessibilityTreeUpdate`
            - Used to apply to snapshot tree
            - Individual actions (operation=[Add|Remove])
            - `oldNode=<id>`
            - `newNode=<id>`
        - Bounding Boxes
            - Accessibility bounding boxes are normally screen coordinates
        - Hit-Testing
            - Hit-testing onto the AccessibilityStaticObject instead of the RenderObject
            - Depth-first traversal of the tree in reverse pre-order to find the element
    - Future Work
        - Parameterized attributes
            - E.g. text bounding box
            - May require blocking main thread to query DOM tree
            - Should cache enough data
            - Maybe split text into inline text boxes
            - A sequence of same style characters within the same line
            - Store relative frame of each character
        - Pass a serialized tree to UI Process
            - Pro: break the limitations for system Accessibility APIs
            - Con: Security concerns
- Implement Static Accessibility Trees
    - Off main thread computation
    - Separate AX tree generation
    - Reduce IPC calls by caching frames