From January 2025 to February 2026, I was the Digital Accessibility Intern at TechSmith, a screen capture and editing software suite with over 73 million downloads worldwide. This page outlines some of my main contributions, such as leading user interviews with 14 users with disabilities, remediating issues in key workflows, creating tutorials for customers with disabilities and for content creators, leading workshops for designers and programmers, and more.
I worked primarily with the accessibility working group, a team of eight people including UX designers, quality assurance (QA), and more. The company has four main products: Camtasia, Snagit, Audiate, and Screencast. I collaborated to work on all four, as well as on other initiatives to boost accessibility compliance and maturity, ultimately making the products more usable for customers with disabilities and getting accessibility more integrated across the company.
All-in-one screen recorder, video editor.
Annotated screenshots and video editing.
Text-based audio editing and AI avatars.
Collaborative video sharing and review tool.
I led a user survey and interview initiative, in partnership with a UX Designer and a Marketing Researcher. This was the first user research project in the company focused specifically on disability and accessibility, and it aimed to gauge representation of disability within our customer base, shed light on how users with disabilities interact with our products, and give clear direction for design and development updates.
10% of respondents identified as having a disability. We gathered quantitative data on disability type and which products respondents use and what they use them for, and qualitative data on how their disability affects these tasks. The data was broken down and shared in an all-company meeting to emphasize scale and importance.
Following the survey, I led interviews with 14 people, with UX designers present to answer questions about product features. Vision, hearing, cognitive, speech, and physical disabilities were all represented. I coded transcripts in Dovetail and compiled an insight report to share to teams including designers, developers, and product managers.
Survey data was shared to the entire company in a meeting.
Based on the survey and interview data, I also created two accessibility personas. One is a sighted person who manages blind or vision impaired employees who create support documentation. It highlights needs such as screen reader and keyboard navigable software to maximize efficiency. The other is a user who experiences challenges with cognitive load and fine motor control and prefers a straightforward workflow with large interface components to avoid becoming overwhelmed or frustrated. A UX Lead provided feedback, and after being refined they were shared with the design teams, some of whom had already been requesting them.
Anita is a persona based on survey and interview data. She gets easily overwhelmed with software and prefers a straightforward workflow. View the personas in a text-based slideshow.
Additionally, accessibility issues pointed out were logged in GitHub to ensure barriers faced by real users are removed.
My Role: I collaborated with marketing and UX to co-write the research protocol. After receiving the survey results, I coded the responses and accordingly prioritized users to contact for interviews.
I was the lead interviewer for all 14 interviews, and completed the qualitative coding and wrote the insight report individually.
What I'd Do Differently: Block off more time to observe users' workflows during screen sharing.
I worked hands-on with the products throughout my internship and collaborated with developers to fix issues in key user workflows. For example, the window in Camtasia where users set up their recording had several elements without descriptive alt text, leaving screen reader users without critical context to complete the task of recording a video. I logged these issues and provided recommendations, and developers fixed the issues in a major release.
I also took the lead setting up a testing process for marketing and QA to use after website updates to ensure the user flow of purchasing products does not include keyboard traps. This is critical because it provides a record demonstrating action in case of a potential lawsuit.
The before and after of screen reader compatibility in the Camtasia capture window. Issues were logged and resolved, providing users with full context when navigating the interface.
In addition to remediating issues, a big part of working with software is the Web Content Accessibility Guidelines (WCAG). Since we have many customers in the US government and in universities, we also adhere to Section 508 standards, as well as EN 301 549 for European agencies.
We publicize our conformance via our Voluntary Product Accessibility Templates (VPATs), which are critical for sales when potential customers are comparing our accessibility to our competitors. I participated in or led review sessions for VPATs for all our main products plus ones for our asset library and support docs. Present at the review sessions were product managers, UX, development, and QA. I also created an internal scoring and competitor comparison system used to track both internal trends and comparison to competitors after each update.
My Role: Identifying and logging accessibility issues in the products was done individually, and communication took place with developers to resolve them. With initial guidance from my supervisor on the criteria, I led the product purchase testing process by creating a walkthrough demo and a testing log after the UX designer sent me the user flows. I participated in approximately a dozen VPAT review sessions total and led about a third of them.
What I'd Do Differently: Slightly adjust my communication and support approach to speed up certain processes.
Prior to my joining the company, the accessibility webpage included out-of-date information and was formatted in plain text rather than like the other pages on our site.
To begin the update, I performed a competitive analysis by looking at the accessibility webpages of ten competitors. The analysis focused on what competitors are displaying and how they display it. Based on this, I created a wireframe (pictured) to begin the design process of the page.
I communicated with a UX Design Intern, Lily Bartley, to begin designing the page based on my wireframe. After I wrote the content with feedback from the accessibility working group, she turned the wireframe into a high-fidelity mockup. We still needed to work out a few issues with fitting the content into the blocks provided by the publishing platform, so once this was worked out the page was published.
The result was an accessibility information hub that provides potential customers with easy access to our compliance reports, and points current customers toward resources for using our products accessibly and for making their own content accessible.
The wireframe included things like highlighted accessibility features. The fleshed out high-fidelity result can be seen below.
View the full, text-based wireframe document.
My Role: I conducted the competitive analysis and created the wireframe individually. While Lily was creating the high fidelity final design, I collaborated on the content and information architecture when needed.
What I'd Do Differently: Provide more detail about the written content a bit earlier in the collaboration process.
I led four company workshops, with the objectives of increasing empathy and building knowledge as part of "shifting left," or beginning accessibility procedures earlier in the design and development process.
Workshops were virtual to accommodate remote staff and featured approximately 15-30 attendees, with some repeat attendees and some standalone. Roles included UX, development, QA, and customer support.
They began with an overview of the day's topic, playing accessibility games to loosen up, a demo of the day's tools and techniques, an exploration exercise, and group discussions and reflections.
Topics included:
Screen reader familiarity and exploration.
Writing acceptance criteria.
Developer accessibility checklists.
Accessibility lingo for support staff.
Workshops included activities like screen reader exploration.
Attendees were engaged, and we closed all workshops by discussing action items to take into our own work. These action items led to meaningful conversations. For example, by brainstorming acceptance criteria for cloning a user's voice in Audiate, attendees realized that considerations for people with speech disabilities were needed since the process involves the user reading a sample script.
My Role: I designed and led the workshops independently, with feedback from the accessibility working group members (and product owners when necessary) leading up to each one.
What I'd Do Differently: Don't go it alone! Enlist more partners to dig into certain topics before the workshops.
The TechSmith Academy is a resource hub where users can find videos to up their game when using our products. I created four articles aimed both for users with disabilities and for content creators.
For users with disabilities, the articles provide details on how to use our products with screen reader and keyboard navigation (with a demo) and other features. For content creators, it explains the importance of accessibility and provides an easy-to-digest overview of things such as alt text and captions with tips to make their content usable by as diverse a range of people as possible. The articles are in a standalone category to ensure they are prominently displayed and easy to access.
Articles include tips like writing effective alt text.
My Role: I wrote the articles individually, and received feedback primarily related to plain language wording and the publishing process from Customer Ed.
What I'd Do Differently: Keep working on writing in plain language.