Best Accessible DevPortal - DevPortal Awards 2022

In this article, learn about the DevPortal Awards, this year’s judges, and why we won the Best Accessible DevPortal award.

DevPortal Awards 2022

The DevPortal Awards showcases and celebrates innovative developer portals and the teams behind them.

The jury of respected industry experts looks for developer portals that deliver the best solutions available today, and that push the boundaries of what are believed to be the key components of a developer portal into the future.

In 2022, 41 developer portals were nominated in 15 categories. Each nominee competes for the best overall and the community prizes.

Developer Experience

• Best Community Outreach & Support
• Best Findability of Products in a DevPortal
• Best Onboarding
• Best API Reference Documentation
• Best Visual Design

Operational Excellence

• Best Accessible DevPortal
• Best International & Localized DevPortal
• Best use of Analytics in a DevPortal
• Best New DX Innovation

Business Alignment

• Best DevPortal Beyond REST Platforms
• Best DevPortal for Citizen Developers (Low/No-Code)
• Best served API Business Model
• Best use of Monetization

Best Overall Developer Portal

• Best SME DevPortal
• Best Enterprise DevPortal
• Community Prize

Judges

The DevPortal Awards are a peer-reviewed award where jury members are invited and assigned to categories according to their expertise. In 2022, 11 judges worked on assessing the portals:

• Alex Akimov: Passionate about great Developer Experience and all components of it: intuitive API design, versatile developer tools, simple and comprehensive technical documentation, empowering developer community and authentic developer relations. Alex, as Head of API at Adyen was responsible for APIs that processed more than €500BN in 2021. Currently he is building an API Platform at Monite. Follow him on Linkendin and Twitter.

• Alvaro Navarro: Developer Advocate and Open Source lover, Alvaro worked for over a decade developing and advocating technologies at companies such as Airbus and Amadeus. He is currently working as Developer Advocate at Spotify for Developers, serving as a bridge between external developers and the engineering team. One of his main tasks is ensuring developers have the best Developer Experience possible when using Spotify technologies by building prototypes using Spotify APIs or writing documentation and tutorials.Follow him on Linkedin and Twitter.

• Anne Gentle: Anne is an industry-recognized author whose books promote collaboration among developers and writers. She works as a developer experience manager at Cisco DevNet, the developer program for Cisco platforms to connect, secure, and automate. With her team of experts, she supports developer tools for API design, developer documentation, and developer education including infrastructure integration. She wrote a book called Docs Like Code to demonstrate developer tools and workflows like GitHub and automated publishing and code integration, applied in the technical writing world. She proudly serves on the Workforce Advisory Committee at Austin Community College, pushing the field towards future opportunities in API and developer documentation. Follow Anne on Linkedin and Twitter.

• Anthony Roux: Anthony leads the Developer Relations team at Miro, helping developers build the future of collaboration. Before that, Anthony worked 10 years in the travel industry, 8 of them working on developer-facing products. He built and led the DevRel and API Product Management team at Amadeus, helping startups make travel stressless and accessible to everybody. In his free time, Anthony loves skiing, hiking, and traveling. Follow him on Linkedin and Twitter.

• Anthony Sansone: Anthony has spent 20+ years in the computer hardware, software, and services, specializing in data protection and user security. He has broad experience developing and maturing people and processes in IT groups and departments. His experience ranges from startups to large multinational companies. Follow Anthony on Linkedin and on Twitter.

• Bob Watson: Bob is Senior Technical Writer at Amazon Web Services. Through combining his extensive industry experience and academic research Bob aims to prepare tomorrow's engineers and technical communicators for the diverse challenges they'll face as professionals. You can read his blog at Docs By Design, where he ponders technical writing, API documentation, and the world in general.

• Leah R. Tucker: Leah’s worked in various roles within the tech industry for 15+ years as: a web developer documenting UX standards for her team at HP, a programmer writer launching developer communities to drive documentation at AWS, a principal/staff writer designing APIs at Sabre and developer experiences at Stripe, a principal product manager of an API program and developer portal at Sabre, and as a software integration engineer, where she puts her different experiences into practice as a consultant by making developer experiences as frictionless as possible. Follow Leah on Linkedin and Twitter.

• Matthew Revell: As founder of Hoopy, Matthew provides DevRel strategy consulting and developer targeted content to help clients across the world understand, reach, and work with software developers. He is also the founder of DeveloperRelations.com, the world's largest library of DevRel content, as well as founder of the DevRelCon global conference series. Follow Matthew on Linkedin and Twitter.

• Meenakshi Khatri: Meenakshi has been working as API Product & Business specialist across various Fintech companies for over 12+ years. She brings a broad range of professional experience in launching API-as-a-product and services, roll-out API Innovation transformation programs and building API-related Phygital experience across various industries. Previously worked as Java developer for 6+ years; she understands how to explain Technical jargons easily to the non-technical folks and closely monitors the design and development of APIs in providing best-in-class solutions for customers.In her current role, she works as Global Product Manager, where she launched API Innovation program across Financial services and Card Issuance services and Leads the development of API-innovation solutions to serve global markets. Follow her on Linkedin and Twitter.

• Michael Meng: Michael is Professor of Applied Linguistics at Merseburg University of Applied Science, where he now teaches courses on text analysis, text production, research methods and cognitive psychology in the B. Eng. and M. A. programs in Technical Communication. He presents regularly at conferences such as the European Academic Colloquium on Technical Communication, Write the Docs, or the annual tcworld/tekom conference. Follow Michael on Linkedin.

• Sophie Rutard: Sophie has been working as API strategist for Allianz Trade (formerly Euler Hermes) for years, creating the first customer-facing API of the trade insurance industry, and putting in place a support team and developer portal accordingly. She also has been significantly contributing to EH’s digital transformation program, which resulted in a fully API and cloud-centric IT strategy that is currently being rolled out as a multi-year initiative. In her current position she is Program Manager for Datahub, which is the Backbone of the IT Target Platform in terms of real-time Streaming, Enterprise Datawarehouse, strategic KPI calculations and Data Lake / Algorithm Management Platform; It furthermore includes the Group Data and API governance teams. Follow Sophie on Linkedin.

Best Accessible DevPortal

In the Best Accessible DevPortal category, the Judges are looking for developer portals that follow specific guidelines and practices in order to cater to all users, with consideration for disability types and severity of impairment. This category highlights the standards and efforts that result in digital products accessible by the widest range of people.

During the evaluation process, to identify the winner of the Best Accessible DevPortal category, judges asked questions like:

• Is your devportal accessible to all possible users with consideration for disability type and severity of impairment?
• Do commonly used accessibility audits result in a clean bill of health?
• Is the developer portal designed with an eye to how people with special needs can benefit?
• Is there an alternative access that you offer people when something doesn’t work well for them on the devportal?
• How do you tie accessibility with an overall inclusivity in design structure, consistency, terminology, language, gender, communications, and so on?

Why we won

According to the Jury, they were “pleasantly surprised to see that the PlatformOS Developer Portal team has taken so much care in the accessibility of their portal: from their wonderful Style Guide to the meticulous care of the contrast level in the images.”

We deeply care about accessibility. We address accessibility right from the design phase, where we use Figma’s Able accessibility plugin. We follow the rules for foreground and background color contrast, font size, and graphical objects (like icons, form fields, etc.), to ensure that our site conforms with WCAG AAA.

As another foundation for accessibility, we make sure to only use (and correctly use) semantic HTML — this helps assistive technologies (like screen readers) convey information to their users by following the semantic structure. In addition to ensuring a consistent structure, semantic HTML facilitates web browsers applying default accessibility features for specific HTML elements. For example, buttons allow for keyboard accessibility (can be navigated to and clicked using the keyboard).

We regularly test for accessibility with various tools. Recent test results of the platformOS Developer Portal:

• Lighthouse: Accessibility score 100/100
• WAVE web accessibility evaluation tool - no errors
• AChecker (Web Accessibility Checker): WCAG 2.0 (Level AAA) - no known problems

As semantic HTML is essential for accessibility, we make sure not to style text any other way than through Markdown, which is then translated into HTML. We provide ready-to-use templates for all content types that include all non-changeable content and placeholders with explanations for the sections that are to be contributed by users.

The aspects described above provide a solid technical foundation. But to optimize for accessibility, content needs to be curated with accessibility in mind. To help the community in this regard, we provide the following guidelines in our Documentation Style Guide.

Guidelines for structuring content

• Using headers for structuring content: The Markdown format we use is translated into semantic HTML to help screen readers navigate through our content. We use headers as described in the style guide and follow the templates provided to ensure consistency. We never skip a header level for styling reasons.
• Improving readability by using concise language, writing short paragraphs, and using lists where possible.
• Using alternative text for images and icons, keeping in mind that screen readers read this text out loud.
• If the image serves a function as part of the documentation, we describe the image in detail. Users receive the same information from the alt text that they would receive when viewing the image.
• Including the data for charts or graphs in the alt text.
• When using screenshots to show what the user has to do, the alt text doesn’t repeat the information already described in text.
• Decorative images don't have alt text — it would only be a distraction.
• When inserting an image, we pay attention to the contrast ratio, image quality, and its size in kilobytes. The smaller the image, the more accessible it is. Many people around the world still have poor internet connectivity.
• Providing information as text when using videos - not everyone can interpret video content efficiently.

Guidelines for accessible language

We write so that the language we use is inclusive and global, and reflects our users’ diversity (including, for example, race, gender, ability, location, etc.).

• Definitions for all terminology: We introduce new concepts by starting with a definition, and adding them to the Glossary. We explain acronyms when first used.
• Technical language: We use the most specific word we can to talk about technical concepts and processes. For example, we don't say "take" when we mean "copy", or don't say "put" when we mean "install".
• Gender-neutral pronouns: We don’t use gender-specific, third-person pronouns such as he, she, his, and hers. We use the second person when possible, and "they" when needed.
• Descriptive link text: To help keyboard navigation, we add the information into the link text. For example, instead of writing "learn more" or "click here", we write the topic title.
• Avoiding ableist language: We don't use words that assume an ability the user might not have (for example, "as you can see" implies the user has a capacity for vision). We avoid directional language, for example, "blue button" or "button below the headline".
• Never perpetuating racism, bias, and harm: We replace terms like "blacklist" and "whitelist" with terms like "allowed" or "blocked", or replace "native" with "built-in".
• We avoid metaphors and colloquialisms.

This recognition means a lot to us. We have been continuously educating ourselves and improving the accessibility and inclusiveness of our devportal for years. We will keep advocating for accessibility on all platforms that are available to us, so please follow us if you’re interested in this topic.

Thank you to the organizers for all their work behind the scenes, and the judges for providing their expertise and for the amazing effort in evaluating all the nominees in the various categories. We are honored and grateful for such great recognition. We would like to thank all members of our team and community who contributed to our developer portal. We couldn’t have achieved this without all of you.

Related

• Interview with the DevPortal Awards Jury 2022
• Best Developer Portals 2022