When do you think about accessibility when you’re building products?
Aaron O'Leary
41 replies
Hey Makers 👋
Aaron from Stark here. A lot of us will likely be bfuilding and launching products throughout the year—so it’s a good time to strategize on how we approach accessibility efforts. I wanted to ask where in your product lifecycle you start thinking about accessibility?
Replies
Lisa Dziuba@lisadziuba
not there yet 😂
Share
@lisadziuba Lisa, I'd be interested to know where "there" is for you? How do you think about that?
in the beginning. Our products must be accessible in order to be pushed in production.
It really depends on your customers/users, if your customers are persons with disabilities or elderly people it makes sense to start with accessibility before you build anything. If you are a startup building a MVP / trying to find a product market fit, you have to make a business decision that are you ready to loose those customers that can not use your product? 15% of persons can't use products because they are not properly designed. So it depends on your customer base. In EU we will have the European Accessibility Act which has a set of rules for creating accessible software, I think it is a good first step.
Hi @infr! I like your point about the fact that you're very much so losing out on customers by failing to consider accessibility in your product's design (15% is a lot, and that number goes up when you consider life stages we all cycle through!)
One thing I think is important to consider is that there is a cost to deferring accessibility — not just in terms of the customers you lose out on, bu in terms of work that must be done to make an inaccessibly designed product accessible. The earlier the better!
@matt_sven absolutely if you have secured the funding for building the product and you know it has a lifecycle. But if you are a startup without real traction you should really focus on building your MVP with the emphasise on the minimum, nothing additional, only focusing on the customer value, you probably will scrap most of the product anyway. Of course if you are an experienced developer/designer making accessible software comes quite naturally and does not require that much extra effort. When you start seeing any traction you know that this is the product you should focus on, start then focusing on scalability and accessibility (and a lot of other things).
Have Stark made any calculations how much additional effort accessibility will add to the development phase? I had to check out your product, I really liked the Chrome extension!
From the first day on. I learned the importance of accessibility in my computer science courses, where some students were blind and were happy about well-structured Markdown-Files we provided them for studying. So important to think about it in every project that you start, not only in software.
@matt_sven The simplicity to write (for us) and browser compatibility to display everything as expected and having the possibility to use good screen readers for the students. In fact, we oftentimes use AsciiDoc, but the idea behind it is the same.
post-MVP or post beta phase!
Used to work for companies to become AAA compliant, definitely seen the importance once the product hits the general public
@jonathanm Curious to know why post beta phase and say not before?
Our methode is:
- Defining how our ideal functionality would look like.
- Then how it could be used for a 5 years old
- How it could be used for someone with visual limitations.
@eudald_camprubi I'm interested to understand the concept of a 5 year old. Why that specific age? And can you say more about the limitation to just visual disability?
@imcatnoone what we work with when we focus on accessibility is working on color contrast size of fonts and follow as much as we can the standards of W3C standards.
About the "5 years old" it was more a way to say, "we try to make things easy to understand" to everyone.
I create webapps, and in my case, I think about accessibility in the architecture layer.
Instead of trying to offer a frontend that is accessible by every case, I try to offer an API so a specific front can be built for every case.
If there is a collective with specific needs that are not met by the default front, they can tailor their own front on top of the API.
@antonio_fernandez_porrua Woah this sounds really interesting. Can you share an example of an API you've built and how it offers flexibility?
@matt_sven Good question. Because you find the flaw in my approach,
I was not documenting any API at all, and I was not publishing that the API is available, so they have never really been public APIs.
And you have made me realize that I was just justifying myself.
I still believe the approach is good. I just need to start taking it seriously.
As a first step, I am adding it to the backlog, and I will send you a message when I finish. Give me 2 weeks.
@matt_sven
I'm not quite sure I've got it right, but It's a start:
I think if creating APIs for accesibility becomes a thing, it needs to have some conventions or standars on at least where to find the basic information.
Also I'm pretty sure I'm not the most qualified to come out with a propper standard and even lest to explain it right, (because I'm not english native)
But here is my first naîve approach os such standarization for APIs for accesibility:
https://github.com/hacknlove/API4H
I choosed markdown over html because people can get too creative with html which can hurt accesibility of this basic information.
Also I choosed markdown over text files, because markdown bring a normalized way to extructure the content.
SO, the idea is to make this information accesible so the same people with needs the alternative UX can create themselves.
------
And this is my current proyect, where I have added for the first time an API for accesibility:
https://www.exnge.com/
Following the proposed standard, anybody that wants to create an alternative user interface can try https://www.exnge.com/API4H/inde... to checkout if an API for accesibility is available,
Then at https://www.exnge.com/API4H/vers... can see the versions availables
In this case then he or she will go to the 1.0.0 version documentation https://www.exnge.com/api/API4H/... and will start creating his interface
For instance using https://www.exnge.com/api/API4H/... to get the most relevant and updated market predictions.
And that's it.
Another thing I would like to add, working on these endpoints has helped my to improve the code quality.
@antonio_fernandez_porrua This is a really interesting idea! Can you share how you you imagine these alternative interfaces are built? Is it by the users needing more accessible interfaces themselves, hobbyists, software vendors, etc...?
@matt_sven I think empowering the final users that need the alternative interfaces is a must-have of any approach to bring accessibility this way. The process to bring accessibility should be accessible itself.
I have once attended a conference of a blind developer and It was awesome how he works, the speed of the screen reader was way beyond my listening skills.
I think the main limitation is not inside (the lack of capacity) but outside (The lack of APIs and documentation).
Maybe in the real world, most of them would be done by associations and foundations, and in some cases, there could be a market opportunity for a startup to build its business around an alternative implementation of some successful product.
Let's say, you can build an alternative tinder interface for blind people, but it's not a clone with no users, it's tinder. This could be a business. But I guess it requires some legal guarantees that tinder is not going to close the API and make its own adapted interface.
Another scenario could be a Wikipedia alternative interface done by a ONCE
And a change.org alternative interface could be done by an activist who happens to be blind.
from the start.. if it's a serious project anyway!
When just hacking together a fun little side project, it shouldn't be the case, but making it accessible takes more time and effort, since we have to add these extra tags and information to the HTML manually.
Would be so good if HTML tags were somehow accessible by default..I know there are libraries like Chakra-UI with accessible components, so those are a big help
@graeme_fulton Hi! What kinds of instances have you come across where the default accessibility of certain HTML tags and whatnot have let you down?
@matt_sven they don't let me down, it's extra work to add them. Like describing an image with an alt tag takes extra time, making sure the tab index is the right order, adding keyboard navigation to a dropdown menu - I have to do it all manually... Would be good if something could assist that part!
@graeme_fulton Do you have any thoughts about things that could make it feel more fun?
@matt_sven something scans all my missing alt tags, and gamifies it, giving me points for every accessibility fix I make, and then puts me in a leaderboard. Top accessbility warrior every month gets bonus points that can be traded in for Stark swag
Accessibility normally isn’t difficult unless you think of it as a feature to add that needs to be individually added to your product. It’s not, it’s something that’s present throughout the development process. Whenever you are building a feature, you’re making decisions that affect its accessibility.
Start with an accessible product from the beginning and it’s _much_ easier than trying to retrofit it later. Virtually every time I hear somebody complain about how difficult accessibility is, they are describing how painful it is to fix a million problems that have accumulated into a mountain because they’ve ignored accessibility throughout the entirety of their product’s development. Don’t create that pain for yourself, just do it right from the start.
Same goes for security. You don’t build an insecure product and then add security in later. You avoid writing insecure code from the start. Same goes for accessibility. Avoid writing inaccessible code from the start.
To some extent from the start, we designed our product from the ground up with accesibility in mind. We wanted to make it something that anyone could use with just a few clicks, and we do have elderly people using our platform who have never played a video game before which is fantastic. That said,there are many aspects of accessibility that we haven't covered that I hope to cover in future, as a communications platform that relies heaviliy on audio we haven't done much to accomodate those that are hard of hearing but I would love to implement some type of voice to text component in future.
@rosie_higgins_grapevine Hi Rosie! I peeked at your profile — is the product you're referring to Grapevine (which looks very cool, btw!) Voice transcription can be tough, but more and more platforms (Twitter, Slack, Zoom, etc.) are adding it. Were there any unique challenges you faced while building Grapevine's accessibility?
@matt_sven it is indeed :) thanks for the feedback! In terms of challenges, technically the whole app has been a challenge to build. Building 3D virtual worlds natively into the browser combined with audio streaming is not an easy feat 😅. Our biggest challenge is always getting people into the platform, once they're in it's very intuitive but that initial step is where we face the most issues. For example, dealing with connectivity and firewall issues from users in different parts of the world was a big problem for a while, and it's the type of platform where if one user can't connect then the entire group will switch somewhere else, so it really needs to work 99% of the time, luckily we've made great progress towards overcoming these problems over the last few months with the help of consistent user feedback.
Accessibility has to be part of initial design; it cannot be an afterthought. It's far more painful to make an existing product accessible then to build with accessibility as a requirement.
Sembly Personal can be used by people with hearing impairments, thus our product solves the problem of "accessibility" of popular online meetings on all popular platforms.
We do not focus on this, but we are glad that this opportunity is covered by our product :)
For tech products, my ideas of accessibility are:
1. Make it easy for users to try/use the product. Add social one-click logins and take the users to the core value of the product within the first few seconds.
2. Use straightforward copywriting that's common lingo among your user base.
3. Make it easy for users to switch from an alternative.
4. Reduce steps to achieving tasks on the application.
5. Don't force users to set usernames, passwords, and input lots of data before they get to jump into the application.
There are many more, I'd be able to think clearly depending on the product. This is more of a case-to-case situation.
Best of lunch for your upcoming launches 🎉.
@aaronoleary Do @ me whenever you launch anything, I'd love to see those products.
From day one. You can’t bake it in, accessibility in needs to be thought about throughout the development process from idea to release.
Most certainly at the beginning for me but I'll be the first to admit that its something I have sometimes overlooked or haven't put in enough time with so I have put an item on my to-do list after reading this.
Depending on what product/ service you offer will depend on the difficulty of providing accessibility and what stage it is introduced. In my position as a marketer, steps can be taken to cater the process to each client and their needs. Of course, to get clients that require accessibility, our own marketing must be accessible. From the start of online profile building, we have created all of our online content in various formats. If we have a video about best campaign practices, it has captions. Simultaneously we also upload the same content in a carousel format on our other platforms.
I would personally recommend considering the aspects of accessibility early on in the launch of a brand. Particularly with the use of social media, there are many steps you can take that open your product up to a broader range of people. Implementation might not be immediate, but knowing what steps you will take should be addressed.
I have found that the most straightforward steps to implement on an online basis are: structuring form layouts (to be read from top to bottom for screen readers), using descriptive links, avoiding flashing/ fast-moving content, using clear, larger fonts, choosing a colour scheme that presents text clearly and also using recognisable symbols as indicators on your website or landing page.
I think the answer to this question is a matter of case by case, but it is a great discussion.