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