Daniel Arcé

Keyboard access across the production interface

PhotoShelter’s digital asset management platform served more than 80,000 users and hosted over a billion files at the time of this work. Its core menus needed keyboard support. A person who could operate a control with a mouse could encounter a different interface when trying to reach the same control from the keyboard.

I led the WCAG 2.1 audit and front-end remediation. Some repairs concerned the information a control exposed: missing labels and ARIA attributes. Others required changes to how focus moved through the interface. Giving a control a name did not make it reachable, and making it reachable did not settle what its keyboard behaviour should be.

That work also addressed a commercial risk. Institutional contracts associated with $9.2M in annual recurring revenue depended on the product demonstrating the required accessibility compliance. The remediation helped reduce the risk to those existing contracts.

The interface used Polymer and Web Components, with interactive elements inside Shadow DOM boundaries. Those boundaries organised the implementation, but keyboard users still needed to move through a menu as a continuous interaction. Focus and keyboard events did not move cleanly between the components.

I built a custom keyboard layer to bridge them. It kept menu items reachable as people moved between components and supported switching between mouse and keyboard without a separate mode. This was behaviour I had to implement across the interface; changing individual controls’ markup would not resolve the navigation problem on its own.

Carrying the patterns into later changes

The audit identified repairs in the existing product. New development also needed to use the resulting patterns. I established component conventions and review checklists that the team could apply to later work, and mentored four developers on accessibility practices.

I also wrote and maintained Mocha tests used in Jenkins CI/CD pipelines. Those tests supported iterative changes to the production application. Together with the component conventions, they gave the team an established process for changing existing code instead of treating each repair as an isolated implementation.

A workflow prototype that informed Smart Galleries

Alongside the production work, I collaborated with the Chief Architect and UX team on exploratory workflow prototypes. I built a React-based automation prototype so we could try the proposed behaviour and expose integration problems before committing to the production implementation.

That prototype informed Smart Galleries. An internal estimate put the reduction in later implementation effort at roughly 30%. The estimate concerned the later implementation effort; my work was on the exploratory prototype that informed it.

Testing image analysis in the browser

I also built an OpenCV.js prototype to compare image blur without sending the analysis to a backend. It let me test a lightweight image-analysis workflow in a static-file environment, where the browser had to do the processing.

The blur experiment remained a prototype and did not ship as a standalone feature.