Quickbase approach to accessibility
Go to our help center to read an updated version of this post and learn more about Quickbase accessibility.
Quickbase is a mature platform, having been developed and iterated on for 20+ years. The platform currently receives over 2 billion requests per month and has hundreds of thousands of active users. We are committed to ensuring Quickbase is an accessible platform for all of these users, a value you’ll see reflected in the product areas we modernize.
As we continue to invest in adding features and making it more usable and delightful, it is important Quickbase is accessible and inclusive to everyone. This may include users with physical disabilities, motor or vision impairments. This is often referred to as “Accessibility”.
As the head of the User Experience team here at Quickbase, my team of designers and I work closely with a dedicated team of developers that are trained in WCAG 2.1 AA standards. Collectively, we support all our development teams and continue to drive progress in this area.
Quickbase aims to meet WCAG 2.1 AA standards in our new and upgraded features that are designed to be consumed by end-users. Improvements are also expected incrementally for builder and app management features. You’ve recently seen innovation in reports and dashboards, and 2022 will bring a major overhaul of our forms experience.
We recognize that accessibility is a process, not a project. Committing to accessibility benefits all our users; not just with a disability. 2020 was a year spent laying the foundation for future accessibility work, much of which came to light in features released in 2021. This foundation included several strategic updates such as building a base layer of accessible components to be utilized in many types of features, adding automated testing tools, and establishing a manual testing workflow.
For example, below - the image shows one of our reusable toolbar component specs. You can see this in many areas of the product where we provide controls for smaller user actions like filtering for reports. Most recently, we upgraded the report settings to be in a panel on Kanban reports. The toolbar is documented with keyboard access for getting in and out using your keyboard. Each of our reusable components is documented in this way starting at the design phase.
|
|
|
Keyboard navigation is a critical aspect of accessibility and something that many power users rely on. This level of detail in our design and development ensures a thoughtful and consistent experience throughout Quickbase. The video below shows how our date picker component can be navigated using your keyboard. Having the specs for new components allows our dev team to build with accessibility in mind.
Before/after feature examples
Our commitment to accessibility is aligned with our General Availability (GA) dates for a given new feature. While a portion of the feature may have enhanced accessibility during beta, audits and further tweaks occur during our final release readiness processes. Bugs, defects, and enhancement requests surrounding accessibility will be addressed in order of priority. Below are some example features that illustrate what it means for a feature to be accessible.
Dashboards/pages
Adding a filter to a dashboard
| Before | After | |
|
Early in the development process, we had not yet finalized our accessibility standards. Initially, users could not use their keyboard in an accordion. This meant that they could not fill out the required fields to add a filter to a dashboard. |
Users can now use their keyboard to navigate into the accordion and through the entire filter page. The underlying accessibility updates allow all users to access the needed form fields to add a filter. |
Administration
Manage users dialog
| Before | After | |
|
Previously, when a dialog was opened, the focus remained on whatever element triggered the dialog and users did not have a way to move focus to the dialog. |
Dialogs now follow the recommended accessibility pattern and have focus manually moved to them when they are opened, easily allowing users to interact with and navigate through them. |
Table report
Updated toolbar button labeling for screen readers
| Before | After | |
|
The toolbar in the old table report had several accessibility issues including labels not being associated with buttons or elements being styled to look like buttons but not being keyboard accessible, interactive page elements. |
In the new table report, toolbar icon buttons were given ARIA labels to surface their functionality to screen-reader or other assistive technology users and all interactive elements are keyboard navigable. |
More actions menu access
| Before | After | |
|
Previously the more actions menu was in the page tab order, but the menu could not be opened or interacted with via the keyboard. |
Users are now able to navigate to and interact with the more actions menu using only their keyboard. When they are done using the menu, focus returns to the more actions button and users can continue moving through the page. |
Pagination access and navigation
| Before | After | |
|
The pagination in the legacy table report style was difficult to navigate to and not all elements were in the page tab order. |
The pagination in the new table report was updated to allow greater keyboard navigation and interaction. All elements are accessible and operable via keyboard. Additionally, more properties were added to the pagination to allow screen reader “rotor” features to find and navigate directly to it from anywhere on the page. |
Timeline report
Keyboard navigation in timeline reports
| Before | After | |
|
The original grid that included the timeline report was not accessible via the keyboard. Users were not able to navigate through the table to access timeline range bars or other elements. |
When developing the new timeline report, the team manually tested to ensure that users were able to access and interact with timeline bars as needed. Users can move through the timeline report using their arrow keys and trigger additional information using their spacebar or enter keys. |
FAQs
What standards does Quickbase follow for coding of interfaces (if 508, what parts, if WCAG 2.0, which level)?
Quickbase aims to meet WCAG 2.1 AA standards in our new and upgraded features that are designed to be consumed by end-users.
What is the Quickbase accessibility conformance testing process?
Our accessibility testing process includes automated testing, manual testing with our QA team, and External 3rd party audits.
Does Quickbase have clients who require accessibility (Federal government, international, local company policies)? If so how are they ensuring Quickbase meets their requirements?
We have thousands of customers that use Quickbase in many different ways with varying needs with respect to accessibility. We engage with customers on accessibility questions by sharing our roadmap and working with their account teams to understand and prioritize their requests.
While the Quickbase platform is not required to be compliant with specific accessibility laws, we are committed to promoting and improving accessibility for our users with disabilities. Quickbase is addressing accessibility for the platform in our new developments by including features that support specifications of the Web Content Accessibility Guidelines (WCAG) 2.1 AA. For example, updates have been made to features within the dashboards/pages, administration, and various reports, which users may access and use. Upon request, Quickbase will provide its most recent Voluntary Product Accessibility Template for its service(s). With respect to accessibility, Quickbase is open to discussing areas of particular importance to our customers and helping to identify solutions to meet their needs.
Does Quickbase do testing with users with disabilities? If so, can you explain the process and identify, roughly, the range of disabilities and access technologies used?
Our team is currently partnering with an outside vendor to ensure we get coverage with real users with a wide range of disabilities. The assistive devices that our vendor uses are:
Screenreaders - JAWS, NVDA, VoiceOver, TalkBack, Narrator
Magnification - ZoomText, iOS Zoom, Android Zoom, Browser Zoom
Alternative navigation - Dragon NaturallySpeaking, Switch systems, Headmouse, On-screen keyboard
The process includes our trained team members putting together a request with this vendor to have an item, a user flow, or a combination of the two tested. This vendor makes provides detailed reporting on testing means and methods, and is available to help the team to understand the feedback.
What experience coding for accessibility do Quickbase developers have?
We have a dedicated team of developers, QA, and designers that are trained in the WCAG 2.1 AA standards. Not only do they work on developing new features and components for Quickbase, but they each are also designated mentors across all our engineering teams.
Does Quickbase have a roadmap for accessibility going forward?
Yes, we have areas of the product that we are actively working on with new designs and features that will be made accessible to the WCAG 2.1 AA standards. Other areas of the product are not being actively worked on, or are in our roadmap to redesign in the upcoming years. That being said, as a company we take critical accessibility gaps and weigh them with our ongoing efforts for improvement on a regular basis. Please reach out to your account team to discuss this in detail.
Has Quickbase tested and/or developed your mobile apps with accessibility in mind?
Mobile is an area that we are working on more in-depth in the coming year. Our existing team members will be working closely with them as we assess the roadmap for this team. Like other areas of the product accessibility for new features, these updates will follow our WCAG 2.1 AA standards.
If customers find that there are changes that need to be made to web/mobile interfaces/apps, what guarantee can they have that these will be implemented to their satisfaction prior to go-live/going forward?
Quickbase has strict quality standards that we adhere to and accessibility issues are assessed by their severity against WCAG 2.1 AA standards. We take feedback from customers seriously and weigh feedback against all customers and all priorities.
If there are specific concerns blocking implementation, we encourage you to work directly with your account team.
Is the process for enabling the accessibility mode or alternate interface accessible to a person using assistive technology such that a user would be able to independently enable the mode or access the alternate interface?
No enabling or use of alternate is required because Quickbase automatically uses the builder-defined schema of the application (like field names and report names) to inform elements like aria labels. No enabling or use of alternate is required. The accessibility of an application will ultimately depend on how a builder incorporates accessible features into the overall design of an application.
Specifically describe the extent to which Quickbase is accessible to people with disabilities, including people who are blind or have low vision, are Deaf or hard of hearing, have mobility or dexterity limitations, and who have speech impairments.
We are actively working with new designs and features that will be made accessible to the WCAG 2.1 AA standards. Other areas of the product are not being actively worked on currently or are in our roadmap to redesign in upcoming years. That being said, as a company, we take critical accessibility gaps and weigh them with our ongoing efforts for improvement on a regular basis.
What methods did Quickbase use to determine the accessibility of the product?
We used our internal teams that consist of our Quality Assurance (QA) and System Quality (SQ) teams, and our team of trained designers and developers. For ongoing design work of new areas of the product, see the answer above.
To what extent is Quickbase willing to work with customers to improve your product’s accessibility?
We are always looking for feedback from customers on our ongoing and existing product and designs. This goes for accessibility feedback and usability in general. In the course of designing features, we'd be happy to get direct feedback.
Where is the most recent Quickbase VPAT?
Quickbase aims to meet WCAG 2.1 AA standards in our new and upgraded features that are designed to be consumed by end-users on the web. For specific details on how Quickbase complies with WCAG 2.1 AA standards, refer to our latest Voluntary Product Accessibility Template (VPAT). This report assumes applications are built for end users using the most recent features and user interface components provided by Quickbase.Our goal is to incrementally improve accessibility in our builder features, app management features, and mobile platform. Customers can consult with their account team for review. Learn more about how Quickbase approaches accessibility in our help center.
Problems or Questions?
-
If you think there is a specific bug or issue, please open a Tech Support case
-
If you’d like to discuss your account, accessibility plans, and how we can help you be successful, please reach out to your account team
-
For further information, or if you’d like to chat about accessibility, the design team would love to talk to you. Reach out to me to set something up - lsawyer@quickbase.com