How to be a (More) Maker-Friendly AT Vendor

Thank you to all the Assistive Technology vendors out there: the devices you create make everyday activities possible for AT Users every day!

We’d love to work with you to make your products and policies more Maker-Friendly.  To that end, we’ve asked our community of AT Users, Practitioners, Makers and Care-Givers to share their challenges using Assistive Technology products.

We then tried to rework it into a more positive “How To” document that you can use as a guide.  You can find the raw (constantly updated) Google Doc file here:

View the Latest How-To Document

Here is an edited version of the full document as of Sept. 18, 2017.


How to be a (more) Maker-Friendly AT Vendor

1: Provide a datasheet (or at least basic specifications)

Adapting products for use with a particular client is hard.  There’s no reason to add guessing and research on things that the original manufacturing company already knows.  Here’s a partial list of things that you know about your product that aren’t readily available to users or Makers:


  • 1a)  Dimensions: Basic form factor dimensions (height/width/depth) as well as the locations of key items (mounting holes, switches, etc.).  Feel free to just add simplified versions of your CAD images or the like.  These are obviously not secret, and measuring them only delays adaptations.


  • 1b)  Screw Sizes: Ok, this is a dimension as well, but it’s much harder to measure, so please provide the screw sizes of all mounting holes.   It is fine with you having a separate size for each device (ok, not fine…) just tell us what they are.  Ideally, we’d like to see ‘4-40 thread, max depth ½in’ or ‘M3 thread, max depth 20mm.’


  • 1c)  Electrical Specs: It’s great the engineers are using 3.5mm mono (TS) audio jacks for switch input.  However, there’s no standard for the voltages nor the currents that you’ll be running through the switches.  Please provide the nominal & max voltage and currents to expect and polarity (positive to tip or sleeve).  If the device provided is a switch, provide the maximum voltage and current the switch can effectively (and safely) control.


  • 1d) Power Requirements: Likewise, required specs for DC power jacks.  What voltage / current does the device need?  What polarity?  Most power bricks aren’t labeled – one normally can’t pick a random power brick up and say “OH!  I know which device this goes to”.  People move, people have pets that chew cords, people have kids – and suddenly the power brick is missing and the expensive AT is useless.   Sometimes the company will sell you another one.  Sometimes they don’t have one (discontinued model) or the company has gone out of business.  Having the power requirements and polarity clearly marked on the rear or bottom of the device / next to the power jack is a huge help and prevents frying electronics by swapping out random adapters.  

2: Leverage existing (consumer) standards

Before creating an internal or proprietary standard, please look at the consumer market and see if there are other solutions already available.  For example:


  • Camera Mounts: The standard for camera mounts are a female ¼”-20 socket on the bottom of the camera.  This is actually an ISO standard and has been used for over 50 years.  This is a great standard for mounting lightweight electronics such as switches, eye-gaze cameras, braille terminals, etc.  And since they are ubiquitous, your users will be able to use any of the thousands of mounts available on Amazon and at photo shops like B&H Photo for a fraction of the custom AT mount price.
  • FDMI or VESA (TV/Monitor) Mounts: Similar to the Camera Mounts, VESA mounts are the standard for holding heavier TVs and Monitors.  There are quick-release VESA mounts, post-mounted arms, wall-mounts and even “back of the car headset” mounts.  All have the standard 75mm and 100mm screw holes.  Your device simply needs to have four M4 holes at 75mm x 75mm square in the center of the back.  If you can’t retrofit your devices, work with us and we’ll create a 3D printed adapter for you at no cost.
  • Bluetooth HID: Every PC and tablet now comes with the ability to attach a bluetooth HID (Human Interface Device) as a keyboard.  Most include Mouse and Joystick support as well (iOS is the notable exception here, they don’t support mice – BAD Apple!).  This means there are hundreds of keyboards and keyboard-like devices that can be used to control these devices.  Please use this as one of your inputs for switch control.  Just let people assign keystrokes to switch taps and enable the underlying Bluetooth device in your tablet or device.  This provides an exceptional point for adaption – check out Chris Young’s guide on this subject.  


3: Publish your Protocols & File Formats

If you really can’t find a standard that fits your needs (hint: look harder), or you’ve already made a decision to use a proprietary protocol to communicate between your devices, please publish the protocol’s specification.  This could go in the Datasheet (see tip #1) or simply be a separate support document for your products.

As an example, take the Wireless Switches sold by various AT vendors.  When they were created, Bluetooth may not have been stable enough.  Or perhaps it was just simpler to pair the sender/receiver at the factory and use basic 433Mhz RF (like a garage door opener).  Or maybe a particular protocol was already in use by the company you acquired.  These are all reasonable, and we get it.

But now, tell us what the protocol is.  433Mhz RF is something we can interface with.  Especially if you’re using something common like a garage door opener.  Using Infrared? That’s fine – tell us the codes you’re sending for on/off.  

We can decode all of these protocols (sniffers/analyzers/oscilloscopes are cheap)… they are not secrets you can keep.  However, don’t make us do the investigation blind – we will make mistakes, make less successful solutions, and waste time that could be spent on more important work helping others.

4: Liberate your dead technology

Sometimes your technology becomes obsolete: that’s life.  You come out with a new version using a new standard and don’t want to support your old version – so you end-of-life it and offer a replacement.  That’s fine.  

However, sometimes you decide that an entire product line is going away.  A whole class of device is no longer going to be sold or supported.  A good example would be the Intellikeys customized keyboards: they are gone and from what we’ve been told there will be no replacement.  

Update: Ablenet has decided to Open Source the drivers for Intellikeys USB – a huge opportunity for the community to support the end-users of this old-but-still-useful technology!

In this case, please consider liberating them; this may be the only technology someone can use – it’s not “that’s life”, but rather “their life”.  There are several things you can do: first make sure that any patents no longer apply.  If they have not expired make a statement allowing anyone to create replacement products.

Then, consider open-sourcing the drivers for the old products.  Communities that use your products can take these, put them on GitHub and provide some best-effort support for them.  You may not be able to release the entire source code, but even if you publish just the interfaces and then make it clear you will not try to interfere with community support that’s a huge help.


5: Let your Technologists Engage

Sometimes nothing is better than talking to the original engineer.  If your technical folks are willing, ask them to monitor and engage in Facebook Groups, Twitter Chats and other gathering places of Makers.  If there’s a Makerspace near your headquarters, send them there to see what’s new in the world of the Maker: they’ll love it and you’ll get great ideas for your new products .

6: Make your products repairable

Everyone agrees that AT Solutions are not cheap.  By definition, then, they should not be disposable.  Most will break in ways that are easy to understand (they were dropped/soaked/thrown) and sometimes easy to fix.  However, some things AT Vendors do make this hard.

6a) Don’t seal your cases

Much of what’s inside your cases is beyond the abilities of your average Maker.  However, corroded battery terminals, broken wires, blown fuses, are very much fixable.  Even the ability to open the case, place it in rice or a desiccant (DampRid) may be all that’s needed after it is dropped in the toilet.


6b) Use user-serviceable batteries/etc.

Battery Interrupts don’t exist for a Li-ion battery that’s soldered directly to the circuit board.  A jumper on the board we can ‘switch’ or plugging in the battery instead of soldering it would be a big help.  

6c) Use standard screws and bolts.

Some devices are put together using specialized fasteners that require a specific tool in order to open a device for repair.  Older communication devices that are considered obsolete are a good example of this practice. Some could be repaired with a simple solder, however if I can’t open the case without shipping it to the company it isn’t worth the cost of shipping & labor to open it.

6d) Protect against back-polarity power

If you are using a device with DC power jacks, label the device with the exact polarity, voltage, and current requirements (see 1d).  However, assume that at some point somebody will plug a cord in “that fits” that is the wrong polarity.  Either have the device be polarity agnostic, in which it works given the proper voltage, regardless of polarity, or does nothing with reversed polarity – but it should not damage the device.  A single diode (costing a few cents) is enough to protect your equipment from someone plugging in a reverse-polarity DC adapter.  The same thing is true if the device uses batteries – plugging in batteries the wrong way should never destroy the device.  Assume that someone will put the batteries in backwards (extra true if you make devices for low vision/blind).  

7: Include AT makers in your testing strategy

You know that testing is a critical part of the development phase. Bad design for an expensive products that don’t work in real world environments cause unnecessary failures and lead to dissatisfaction all around. For example: we bought some pillow switches, only to discover that every time the switch was activated, it created a scissoring action on the wires. Eventually the wires failed. Not only that, but we had to break the switch open to solder the wire — see point 6a.

The community of ATMakers can be a force multiplier for effective testing of new products or designs. We are geographically distributed yet digitally united, quick to respond to inquiries, passionate about quality and user experience, always on the lookout for new projects, and willing to share feedback with (and about) vendors who want to listen. Many of us represent (in a completely unofficial capacity) a much broader community of potential users who, in the digitally connected age are looking more and more to the most knowledgeable and capable users in their community of abilities / needs for cues on which solutions give the best “bang for buck.”

Include people (several, plural, more than one) with the disability in question in the testing strategy as well.  This should be assumed, but we see examples on a regular basis from big names in the industry where this was obviously not done.  Design your device for the end users who will actually be using it; design for the Makers supporting/adapting it.  

8.  Share the products testing scenarios.

If you’ve tested a switch for durability by robotically operating it 500 times while it is face up on a surface, let us know that.  We’re not looking to judge or compare, but it will help us determine if we are using the device outside of your tested parameters.  Thus, expecting it to perform in a manner you either didn’t intend or hadn’t considered.  Maybe using it while mounted face down could cause internal components to come in contact with moving parts and shorten the life of the product.  If that happens, a few of the other items in this document would not only allow us to repair it, but adapt the interior to unique conditions.  We would gladly share such findings so you could evaluate whether or not to include such adaptations during production.