diff --git a/src/accessories/index.html b/src/accessories/index.html
new file mode 100644
index 0000000..a6502a5
--- /dev/null
+++ b/src/accessories/index.html
@@ -0,0 +1,7 @@
+<!DOCTYPE HTML>
+<html>
+<head>
+<title>Android</title>
+<meta http-equiv="REFRESH" content="0;url=/tech/accessories/index.html">
+</head>
+</html>
diff --git a/src/tech/accessories/aoap/aoa.md b/src/tech/accessories/aoap/aoa.md
new file mode 100644
index 0000000..e806eaf
--- /dev/null
+++ b/src/tech/accessories/aoap/aoa.md
@@ -0,0 +1,135 @@
+# Android Open Accessory Protocol 1.0 #
+
+An Android USB accessory must adhere to Android Accessory Protocol, which defines how
+an accessory detects and sets up communication with an Android-powered device. In general, an
+accessory should carry out the following steps:
+
+- Wait for and detect connected devices
+- Determine the device's accessory mode support
+- Attempt to start the device in accessory mode if needed
+- Establish communication with the device if it supports the Android accessory protocol
+
+The following sections explain how to implement these steps.
+
+## Wait for and Detect Connected Devices ##
+
+Your accessory should have logic to continuously check for connected Android-powered devices.
+When a device is connected, your accessory should determine if the device supports accessory mode.
+
+
+## Determine Accessory Mode Support ##
+
+When an Android-powered device is connected, it can be in one of three states:
+
+- The attached device supports Android accessory mode and is already in accessory mode.
+- The attached device supports Android accessory mode, but it is not in accessory mode.
+- The attached device does not support Android accessory mode.
+
+During the initial connection, the accessory should check the vendor and product IDs of the
+connected device's USB device descriptor. The vendor ID should match Google's ID (`0x18D1`) and the
+product ID should be `0x2D00` or `0x2D01` if the device is already in accessory mode (case A). If
+so, the accessory can now
+[establish communication with the device](#establish-communication-with-the-device) through
+bulk transfer endpoints with its own communication protocol. There is no need to start the device
+in accessory mode.
+
+**Note:** `0x2D00` is reserved for Android-powered devices that
+support accessory mode. `0x2D01` is reserved for devices that support accessory mode as well as the
+ADB (Android Debug Bridge) protocol, which exposes a second interface with two bulk endpoints for
+ADB. You can use these endpoints for debugging the accessory application if you are simulating
+the accessory on a computer. In general, do not use this interface unless your accessory is
+implementing a passthrough to ADB on the device.
+
+If the vendor and product ID do not match, there is no way to distinguish between states b and c, so
+the accessory [attempts to start the device in accessory mode](#attempt-to-start-in-accessory-mode)
+to determine if the device is supported.
+
+
+## Attempt to Start in Accessory Mode ##
+
+If the vendor and product IDs do not correspond to an Android-powered device in accessory
+mode, the accessory cannot discern whether the device supports accessory mode and is not in that
+state, or if the device does not support accessory mode at all. This is because devices that
+support accessory mode but aren't in it initially report the device's manufacturer vendor ID and
+product ID, and not the special Android Open Accessory ones. In either case, the accessory should
+try to start the device into accessory mode to figure out if the device supports it. The following
+steps explain how to do this:
+
+<ul>
+  <li>Send a 51 control request ("Get Protocol") to figure out if the device supports the Android
+  accessory protocol. A non-zero number is returned if the protocol is supported, which
+  represents the version of the protocol that the device supports (currently, only version 1
+  exists). This request is a control request on endpoint 0 with the following characteristics:
+
+<pre>
+requestType:    USB_DIR_IN | USB_TYPE_VENDOR
+request:        51
+value:          0
+index:          0
+data:           protocol version number (16 bits little endian sent from the
+                device to the accessory)
+</pre>
+  </li>
+  <li>If the device returns a proper protocol version, send identifying string information to the
+  device. This information allows the device to figure out an appropriate application for this
+  accessory and also present the user with a URL if an appropriate application does not exist.
+  These requests are control requests on endpoint 0 (for each string ID) with the following
+  characteristics:
+
+<pre>
+requestType:    USB_DIR_OUT | USB_TYPE_VENDOR
+request:        52
+value:          0
+index:          string ID
+data            zero terminated UTF8 string sent from accessory to device
+</pre>
+
+  <p>The following string IDs are supported, with a maximum size of 256 bytes for each string
+  (must be zero terminated with `\0`).</p>
+
+<pre>
+manufacturer name:  0
+model name:         1
+description:        2
+version:            3
+URI:                4
+serial number:      5
+</pre>
+  </li>
+  <li>When the identifying strings are sent, request the device start up in accessory mode. This
+  request is a control request on endpoint 0 with the following characteristics:
+
+<pre>
+requestType:    USB_DIR_OUT | USB_TYPE_VENDOR
+request:        53
+value:          0
+index:          0
+data:           none
+</pre>
+  </li>
+</ul>
+
+After sending the final control request, the connected USB device should re-introduce itself
+on the bus in accessory mode and the accessory can re-enumerate the connected devices. The
+algorithm jumps back to
+[determining the device's accessory mode support](#determine-accessory-mode-support)
+to check for the vendor and product ID. The vendor ID and product ID of the device will be
+different if the device successfully switched to accessory mode and will now correspond to
+Google's vendor and product IDs instead of the device manufacturer's IDs. The accessory can now
+[establish communication with the device](#establish-communication-with-the-device).
+
+If at any point these steps fail, the device does not support Android accessory mode and the
+accessory should wait for the next device to be connected.
+
+
+## Establish Communication with the Device ##
+
+If an Android-powered device in accessory mode is detected, the accessory can query the
+device's interface and endpoint descriptors to obtain the bulk endpoints to communicate with the
+device. An Android-powered device that has a product ID of `0x2D00` has one interface with two bulk
+endpoints for input and output communication. A device with product ID of `0x2D01` has two
+interfaces with two bulk endpoints each for input and output communication. The first interface
+is for standard communication while the second interface is for ADB communication. To communicate
+on an interface, all you need to do is find the first bulk input and output endpoints, set the
+device's configuration to a value of 1 with a `SET_CONFIGURATION` (`0x09`) device request, then
+communicate using the endpoints.
\ No newline at end of file
diff --git a/src/tech/accessories/aoap/aoa2.md b/src/tech/accessories/aoap/aoa2.md
new file mode 100644
index 0000000..803c6c5
--- /dev/null
+++ b/src/tech/accessories/aoap/aoa2.md
@@ -0,0 +1,200 @@
+# Android Open Accessory Protocol 2.0 #
+
+This document describes the changes to the Android Open Accessory (AOA) protocol since its
+initial release, and is a supplement to the documentation of the
+[first release of AOA](/tech/accessories/aoap/aoa.html).
+
+The Android Open Accessory Protocol 2.0 adds two new features: audio output (from the Android
+device to the accessory) and support for the accessory acting as one or more Human Interface Devices
+(HID) to the Android device. The Android SDK APIs available to Android application developers
+remain unchanged.
+
+
+## Detecting Android Open Accessory 2.0 Support ##
+
+In order for an accessory to determine if a connected Android device supports accessories and at
+what protocol level, the accessory must send a `getProtocol()` command and check the result.
+Android devices supporting the initial version of the Android Open Accessory protocol return a
+`1`, representing the protocol version number. Devices that support the new features described
+in this document must return `2` for the protocol version. Version 2.0 of the protocol is
+upwardly compatible, so accessories designed for the original accessory protocol still work
+with newer Android devices. The following example from the Accessory Development Kit 2011
+[source code](http://developer.android.com/tools/adk/adk2.html#src-download)
+(`<adk-src>/adk1/board/AndroidAccessory/AndroidAccessory.cpp`) library demonstrates this protocol
+check:
+
+    bool AndroidAccessory::switchDevice(byte addr)
+    {
+        int protocol = getProtocol(addr);
+        if (protocol >= 1) {
+            Serial.print("device supports protocol 1 or higher\n");
+        } else {
+            Serial.print("could not read device protocol version\n");
+            return false;
+        }
+
+        sendString(addr, ACCESSORY_STRING_MANUFACTURER, manufacturer);
+        sendString(addr, ACCESSORY_STRING_MODEL, model);
+        sendString(addr, ACCESSORY_STRING_DESCRIPTION, description);
+        sendString(addr, ACCESSORY_STRING_VERSION, version);
+        sendString(addr, ACCESSORY_STRING_URI, uri);
+        sendString(addr, ACCESSORY_STRING_SERIAL, serial);
+
+        usb.ctrlReq(addr, 0, USB_SETUP_HOST_TO_DEVICE | USB_SETUP_TYPE_VENDOR |
+                    USB_SETUP_RECIPIENT_DEVICE, ACCESSORY_START, 0, 0, 0, 0, NULL);
+        return true;
+    }
+
+AOA 2.0 includes new USB product IDs, one for each combination of USB interfaces available when
+in accessory mode. The possible USB interfaces are:
+
+- **accessory** - An interface providing 2 bulk endpoints for communicating with an
+Android application.
+- **audio** - A new standard USB audio class interface for streaming audio
+from an Android device to an accessory.
+- **adb** - An interface intended only for debugging purposes while developing an
+accessory. Only enabled if the user has USB Debugging enabled in Settings on the Android device.
+
+
+In AOA 1.0, there are only two USB product IDs:
+
+- `0x2D00` - accessory
+- `0x2D01` - accessory + adb
+
+AOA 2.0 adds an optional USB audio interface and, therefore, includes product IDs for the new
+combinations of USB interfaces:
+
+- `0x2D02` - audio
+- `0x2D03` - audio + adb
+- `0x2D04` - accessory + audio
+- `0x2D05` - accessory + audio + adb
+
+
+## Audio Support ##
+
+AOA 2.0 includes optional support for audio output from an Android device to an accessory. This
+version of the protocol supports a standard USB audio class interface that is capable of 2 channel
+16-bit PCM audio with a bit rate of 44100 Khz. AOA 2.0 is currently limited to this output mode, but
+additional audio modes may be added in the future.
+
+To enable the audio support, the accessory must send a new USB control request:
+
+    **SET_AUDIO_MODE**
+    requestType:    USB_DIR_OUT | USB_TYPE_VENDOR
+    request:        58
+    value:          0 for no audio (default),
+                    1 for 2 channel, 16-bit PCM at 44100 KHz
+    index:          0
+    data            none
+
+This command must be sent _before_ sending the `ACCESSORY_START` command for
+entering accessory mode.
+
+
+## HID Support ##
+
+AOA 2.0 allows the accessory to register one or more USB Human Interface Devices (HID) with
+an Android device. This approach reverses the direction of communication for typical USB HID
+devices like USB mice and keyboards. Normally, the HID device is a peripheral connected to a USB
+host like a personal computer. But in the case of the AOA protocol, the USB host acts as one or more
+input devices to a USB peripheral.
+
+HID support in AOA 2.0 is simply a proxy for standard HID events. The implementation makes no
+assumptions about the content or type of events and merely passes it through to the input system,
+so an AOA 2.0 accessory can act as any HID device (mouse, keyboard, game controller, etc.). It
+can be used for something as simple as the play/pause button on a media dock, or something as
+complicated as a docking station with a mouse and full QWERTY keyboard.
+
+The AOA 2.0 protocol adds four new USB control requests to allow the accessory to act as one or
+more HID input devices to the Android device.  Since HID support is done entirely through
+control requests on endpoint zero, no new USB interface is needed to provide this support. The
+control requests are as follows:
+
+- **ACCESSORY_REGISTER_HID** registers a new HID device with the Android device.
+The accessory provides an ID number that is used to identify the HID device for the other three
+calls. This ID is valid until USB is disconnected or until the accessory sends
+`ACCESSORY_UNREGISTER_HID` to unregister the HID device.
+- **ACCESSORY_UNREGISTER_HID** unregisters a HID device that was previously
+registered with `ACCESSORY_REGISTER_HID`.
+- **ACCESSORY_SET_HID_REPORT_DESC** sends a report descriptor for a HID device to
+the Android device. This request is used to describe the capabilities of the HID device, and must
+be sent before reporting any HID events to the Android device. If the report descriptor is larger
+than the maximum packet size for endpoint zero, multiple `ACCESSORY_SET_HID_REPORT_DESC` commands
+are sent in order to transfer the entire descriptor.
+- **ACCESSORY_SEND_HID_EVENT** sends input events from the accessory to the Android
+device.
+
+The code definitions for these new control requests are as follows:
+
+    /* Control request for registering a HID device.
+     * Upon registering, a unique ID is sent by the accessory in the
+     * value parameter. This ID will be used for future commands for
+     * the device
+     *
+     *  requestType:    USB_DIR_OUT | USB_TYPE_VENDOR
+     *  request:        ACCESSORY_REGISTER_HID_DEVICE
+     *  value:          Accessory assigned ID for the HID device
+     *  index:          total length of the HID report descriptor
+     *  data            none
+     */
+    #define ACCESSORY_REGISTER_HID         54
+
+    /* Control request for unregistering a HID device.
+     *
+     *  requestType:    USB_DIR_OUT | USB_TYPE_VENDOR
+     *  request:        ACCESSORY_REGISTER_HID
+     *  value:          Accessory assigned ID for the HID device
+     *  index:          0
+     *  data            none
+     */
+    #define ACCESSORY_UNREGISTER_HID         55
+
+    /* Control request for sending the HID report descriptor.
+     * If the HID descriptor is longer than the endpoint zero max packet size,
+     * the descriptor will be sent in multiple ACCESSORY_SET_HID_REPORT_DESC
+     * commands. The data for the descriptor must be sent sequentially
+     * if multiple packets are needed.
+     *
+     *  requestType:    USB_DIR_OUT | USB_TYPE_VENDOR
+     *  request:        ACCESSORY_SET_HID_REPORT_DESC
+     *  value:          Accessory assigned ID for the HID device
+     *  index:          offset of data in descriptor
+     *                      (needed when HID descriptor is too big for one packet)
+     *  data            the HID report descriptor
+     */
+    #define ACCESSORY_SET_HID_REPORT_DESC         56
+
+    /* Control request for sending HID events.
+     *
+     *  requestType:    USB_DIR_OUT | USB_TYPE_VENDOR
+     *  request:        ACCESSORY_SEND_HID_EVENT
+     *  value:          Accessory assigned ID for the HID device
+     *  index:          0
+     *  data            the HID report for the event
+     */
+    #define ACCESSORY_SEND_HID_EVENT         57
+
+
+## Interoperability with AOA 1.0 Features ##
+
+The original [AOA protocol](/tech/accessories/aoap/aoa.html) provided support for an Android
+application to communicate directly with a USB host (accessory) over USB. AOA 2.0 keeps that
+support, but adds new features to allow the accessory to communicate with the Android operating
+system itself (specifically the audio and input systems). The design of the AOA 2.0 makes it is
+possible to build an accessory that also makes use of the new audio and/or HID support in addition
+to the original feature set. Simply use the new features described in this document in addition to
+the original AOA protocol features.
+
+
+## Connecting AOA 2.0 without an Android App ##
+
+It is possible to design an accessory (for example, an audio dock) that uses the new audio and
+HID support, but does not need to communicate with an application on the Android device. In that
+case, the user would not want to see the dialog prompts related to finding and associating the newly
+attached accessory with an Android application that can communicate with it. To prevent these
+dialogs from appearing after the device and accessory are connected, the accessory can simply not
+send the manufacturer and model names to the Android device. If these strings are not provided to
+the Android device, then the accessory is able to make use of the new audio and HID support in AOA
+2.0 without the system attempting to find an application to communicate with the accessory. Also,
+if these strings are not provided, the accessory USB interface is not present in the Android
+device USB configuration after the device enters accessory mode.
\ No newline at end of file
diff --git a/src/tech/accessories/guide/audio.md b/src/tech/accessories/guide/audio.md
new file mode 100644
index 0000000..a1a572a
--- /dev/null
+++ b/src/tech/accessories/guide/audio.md
@@ -0,0 +1,67 @@
+# Building Audio Accessories #
+
+In building an audio accessory, such as an audio dock or other playback device, you should
+consider how your accessory will connect with Android devices. In particular, you should decide
+if your accessory will use Universal Serial Bus (USB) or a Bluetooth connection to stream music or
+other audio content.
+
+
+## Audio over USB ##
+
+An accessory that connects with Android over USB connection must use the Android Open
+Accessory (AOA) protocol version 2.0. This version of the AOA protocol is supported on Android 4.1
+(API Level 16) and higher. Once an Android device connects to an accessory that supports this
+protocol, the Android system treats it as a standard audio output device and routes all audio to
+that accessory. No secondary software application is required on the Android device.
+
+**Note:** Due to the low power output of Android devices, the Android Open Accessory
+Protocol requires that accessories act as a USB host, which means that the connecting accessory
+must power the bus.
+
+
+### Next steps ###
+
+To get started on building an audio accessory that uses a USB connection:
+
+- Select a hardware platform or build a hardware device that can support USB host mode.
+- Review the [AOA 2.0 protocol](/tech/accessories/aoap/aoa2.html) specification to understand
+  how to implement this protocol on your accessory hardware.
+- Review the ADK 2012 [firmware source code](http://developer.android.com/tools/adk/adk2.html#src-download)
+  (`<adk-src>/adk2012/board/library/ADK2/`), which includes an example implementation
+  of an audio playback accessory using a USB connection.
+
+**Note:** The AOA 2.0 protocol also supports the
+[human interface device](/tech/accessories/aoap/aoa2.html#hid-support) (HID) protocol through a USB
+connection, enabling accessories such as audio docks to provide hardware play back controls such
+as pause, fast-forward or volume buttons.
+
+
+## Audio over Bluetooth ##
+
+An accessory that connects with Android over Bluetooth can use an Advanced Audio Distribution
+Profile (A2DP) connection stream music for playback. Playing audio over a Bluetooth with A2DP is
+supported on Android 1.5 (API Level 3) and higher. An Android user can connect to an accessory
+that supports this profile using the system Settings > Bluetooth and play music directly to the
+accessory without the need for a secondary application.
+
+**Note:** If you want to provide a custom application for output to your audio
+accessory, note that the Android 3.0 (API Level 11) allows applications to operate an A2DP
+connection using the
+[`BluetoothA2dp`](http://developer.android.com/reference/android/bluetooth/BluetoothA2dp.html)
+class.
+
+
+### Next steps ###
+
+To get started on building an audio accessory that uses a Bluetooth connection:
+
+- Select a hardware platform or build an hardware device that can support Bluetooth
+  communications and the A2DP connection profile.
+- Review the ADK 2012
+  [firmware source code](http://developer.android.com/tools/adk/adk2.html#src-download)
+  (`<adk-src>/adk2012/board/library/ADK2/`), which includes an example implementation
+  of an audio playback accessory using a Bluetooth connection.
+
+**Note:** The ADK 2012 source code includes an open source Bluetooth stack that
+is built for the Texas Instruments CC2564 chip, but can work with any Bluetooth chip that
+implements a standard Host/Controller Interface (HCI).
\ No newline at end of file
diff --git a/src/tech/accessories/guide/custom.md b/src/tech/accessories/guide/custom.md
new file mode 100644
index 0000000..d4022b0
--- /dev/null
+++ b/src/tech/accessories/guide/custom.md
@@ -0,0 +1,77 @@
+# Building Custom Accessories #
+
+An accessory for Android can be anything: keyboard, thermometer, robot, lighting control or
+anything else you can imagine. Accessories for Android all have one thing in common; they all
+connect to an Android device in some way. When starting out to build an accessory, you should
+decide how your accessory will connect to Android devices. This page gives you quick overview of
+your options for connecting your Android accessory and resources to help you get started.
+
+
+## Connecting over USB ##
+
+An accessory that connects to an Android device through a USB cable must support the Android
+Open Accessory (AOA) protocol, which specifies how an accessory can establish communication with
+an Android device over a USB cable. Due to the low power output of Android devices, the AOA
+protocol requires the accessory act as a USB host, which means that the connecting accessory must
+power the bus.
+
+The AOA protocol has two versions which support different types of communication. Version
+1.0 supports a generic accessory communication and adb debugging. This version of the protocol is
+supported by the platform in Android 3.1 (API Level 12) and higher, and supported through an
+[Add-On Library](https://developers.google.com/android/add-ons/google-apis/) in Android
+2.3.4 (API Level 10) and higher. Version 2.0 of the protocol is available in Android 4.1 (API Level
+16) and adds audio streaming and human interface device (HID) capabilities.
+
+If you use the general accessory protocol to communicate with your accessory (rather than the
+adb or audio protocol), you must provide an Android application that can detect the connection of
+your USB accessory and establish communication.
+
+
+### Next steps ###
+
+To get started on building an Android accessory that uses a USB connection:
+
+- Select a hardware platform or build a hardware device that can support USB host mode.
+- Review the [AOA protocol](/tech/accessories/aoap/index.html) specifications to understand
+  how to implement this protocol on your accessory hardware. Implementing the
+  [AOA 2.0 protocol](/tech/accessories/aoap/aoa2.html) is recommended for all new Android USB
+  accessories.
+- Review the ADK 2012 [firmware source code](http://developer.android.com/tools/adk/adk2.html#src-download)
+  (`<adk-src>/adk2012/board/library/ADK2/`), which demonstrates an implementation of an accessory
+  using a USB connection for general data communications and audio streaming.
+- If you are planning to build an Android application that communicates with your accessory
+  via USB, review the ADK 2012 Android
+  [application source code](http://developer.android.com/tools/adk/adk2.html#src-download)
+  (`<adk-src>/adk2012/app/`).
+
+
+## Connecting over Bluetooth ##
+
+An accessory that connects with Android devices over a Bluetooth connection can use the
+various connection profiles supported by Android, including the Simple Serial Protocol (SSP) and
+Advanced Audio Distribution Profile (A2DP) profile. An accessory that uses Bluetooth to connect to
+Android devices must support Bluetooth communications and at least one of the supported connection
+profiles.
+
+Users must enable Bluetooth on their Android device and pair with your accessory in order to
+use it. You can also provide a secondary Android application that handles any specialized
+communication, such as data input or control outputs, to interface with your accessory.
+
+
+### Next steps ###
+
+To get started on building an Android accessory that uses a Bluetooth connection:
+
+- Select a hardware platform or build an hardware device that can support Bluetooth
+  communications and an Android supported connection profile, such as SSP or A2DP.
+- Review the ADK 2012 [firmware source code](http://developer.android.com/tools/adk/adk2.html#src-download)
+  (`<adk-src>/adk2012/board/library/ADK2/`), which includes an example implementation
+  of general data communications and audio streaming using a Bluetooth connection.
+- If you are planning to build an Android application that communicates with your accessory
+  via Bluetooth, review the ADK 2012 Android
+  [application source code](http://developer.android.com/tools/adk/adk2.html#src-download)
+  (`<adk-src>/adk2012/app/`).
+
+**Note:** The ADK 2012 source code includes an open source Bluetooth stack which
+is built for the Texas Instruments CC2564 chip, but can work with any Bluetooth chip that
+supports a standard Host/Controller Interface (HCI).
\ No newline at end of file
diff --git a/src/tech/accessories/index.md b/src/tech/accessories/index.md
new file mode 100644
index 0000000..17a5039
--- /dev/null
+++ b/src/tech/accessories/index.md
@@ -0,0 +1,39 @@
+# Build Accessories for Android #
+
+Android Open Accessory support allows external USB hardware (an Android USB accessory) to interact
+with an Android-powered device in a special accessory mode. When an Android-powered powered device
+is in accessory mode, the connected accessory acts as the USB host (powers the bus and enumerates
+devices) and the Android-powered device acts in the USB accessory role. Android USB accessories are
+specifically designed to attach to Android-powered devices and adhere to the Android Open Accessory
+Protocol, that allows them to detect Android-powered devices that support
+accessory mode. Accessories must also provide 500mA at 5V for charging power. Many previously
+released Android-powered devices are only capable of acting as a USB device and cannot initiate
+connections with external USB devices. Android Open Accessory support overcomes this limitation
+and allows you to build accessories that can interact with an assortment of Android-powered
+devices by allowing the accessory to initiate the connection.
+
+**Note:** Accessory mode is ultimately dependent on the device's hardware and not all devices
+support accessory mode. Devices that support accessory mode can be filtered using a `<uses-feature>`
+element in your corresponding application's Android manifest. For more information, see the
+[USB Accessory](http://developer.android.com/guide/topics/connectivity/usb/accessory.html#manifest)
+developer guide.
+
+Android Open Accessory support is included in Android 3.1 (API Level 12) and higher, and supported
+through an [Add-On Library](https://developers.google.com/android/add-ons/google-apis/) in Android
+2.3.4 (API Level 10) and higher.
+
+
+## Audio Accessories ##
+
+Android 4.1 and higher has support for audio output over a USB connection or Bluetooth. Find out
+how to build audio docks and other plug-in audio output hardware for Android.
+
+[&raquo; Build Audio Accessories](/tech/accessories/guide/audio.html)
+
+
+## Custom Accessories ##
+
+What do you want to connect to your Android device? Alarm clock? Keyboard? Thermostat? Robot?
+Learn how to connect existing equipment or your own unique hardware to Android.
+
+[&raquo; Build Custom Accessories](/tech/accessories/guide/custom.html)
\ No newline at end of file
diff --git a/src/tech/accessories/sidebar2.md b/src/tech/accessories/sidebar2.md
new file mode 100644
index 0000000..38bf48f
--- /dev/null
+++ b/src/tech/accessories/sidebar2.md
@@ -0,0 +1,9 @@
+# Getting Started #
+
+- [Audio Accessories](/tech/accessories/guide/audio.html)
+- [Custom Accessories](/tech/accessories/guide/custom.html)
+
+# Open Accessory Protocol #
+
+- [AOA 2.0](/tech/accessories/aoap/aoa2.html)
+- [AOA 1.0](/tech/accessories/aoap/aoa.html)
\ No newline at end of file
diff --git a/src/tech/index.md b/src/tech/index.md
index d871a9a..beebebf 100644
--- a/src/tech/index.md
+++ b/src/tech/index.md
@@ -67,4 +67,9 @@
 
 [&raquo; Data Usage Information](/tech/datausage/index.html)
 
+## Accessory Protocol Information ##
+Android devices can connect to hardware accessories, such as audio docks,
+keyboards and custom hardware, through USB or Bluetooth. This document
+describes the Android Open Accessory protocol for accessory hardware builders.
 
+[&raquo; Accessory Protocol Information](/tech/accessories/index.html)
\ No newline at end of file
diff --git a/src/tech/sidebar.md b/src/tech/sidebar.md
index c3701fd..09f2f2f 100644
--- a/src/tech/sidebar.md
+++ b/src/tech/sidebar.md
@@ -5,3 +5,4 @@
 - [Security](/tech/security/index.html)
 - [Input](/tech/input/index.html)
 - [Data Usage](/tech/datausage/index.html)
+- [Accessories](/tech/accessories/index.html)
\ No newline at end of file