Recherche avancée

Sur d’autres sites (8016)

• A systematic approach to making Web Applications accessible

  22 février 2012, par silvia

  With the latest developments in HTML5 and the still fairly new ARIA (Accessible Rich Interface Applications) attributes introduced by the W3C WAI (Web Accessibility Initiative), browsers have now implemented many features that allow you to make your JavaScript-heavy Web applications accessible.

  Since I began working on making a complex web application accessible just over a year ago, I discovered that there was no step-by-step guide to approaching the changes necessary for creating an accessible Web application. Therefore, many people believe that it is still hard, if not impossible, to make Web applications accessible. In fact, it can be approached systematically, as this article will describe.

  This post is based on a talk that Alice Boxhall and I gave at the recent Linux.conf.au titled “Developing accessible Web apps – how hard can it be ?” (slides, video), which in turn was based on a Google Developer Day talk by Rachel Shearer (slides).

  These talks, and this article, introduce a process that you can follow to make your Web applications accessible : each step will take you closer to having an application that can be accessed using a keyboard alone, and by users of screenreaders and other accessibility technology (AT).

  The recommendations here only roughly conform to the requirements of WCAG (Web Content Accessibility Guidelines), which is the basis of legal accessibility requirements in many jurisdictions. The steps in this article may or may not be sufficient to meet a legal requirement. It is focused on the practical outcome of ensuring users with disabilities can use your Web application.

  Step-by-step Approach

  The steps to follow to make your Web apps accessible are as follows :

  1. Use native HTML tags wherever possible
  2. Make interactive elements keyboard accessible
  3. Provide extra markup for AT (accessibility technology)

  If you are a total newcomer to accessibility, I highly recommend installing a screenreader and just trying to read/navigate some Web pages. On Windows you can install the free NVDA screenreader, on Mac you can activate the pre-installed VoiceOver screenreader, on Linux you can use Orca, and if you just want a browser plugin for Chrome try installing ChromeVox.

  1. Use native HTML tags

  As you implement your Web application with interactive controls, try to use as many native HTML tags as possible.

  HTML5 provides a rich set of elements which can be used to both add functionality and provide semantic context to your page. HTML4 already included many useful interactive controls, like <a>, <button>, <input> and <select>, and semantic landmark elements like <h1>. HTML5 adds richer <input> controls, and a more sophisticated set of semantic markup elements like such as <time>, <progress>, <meter>, <nav>, <header>, <article> and <aside>. (Note : check browser support for browser support of the new tags).

  Using as much of the rich HTML5 markup as possible means that you get all of the accessibility features which have been implemented in the browser for those elements, such as keyboard support, short-cut keys and accessibility metadata, for free. For generic tags you have to implement them completely from scratch.

  What exactly do you miss out on when you use a generic tag such as <div> over a specific semantic one such as <button> ?

  1. Generic tags are not focusable. That means you cannot reach them through using the [tab] on the keyboard.
  2. You cannot activate them with the space bar or enter key or perform any other keyboard interaction that would be regarded as typical with such a control.
  3. Since the role that the control represents is not specified in code but is only exposed through your custom visual styling, screenreaders cannot express to their users what type of control it is, e.g. button or link.
  4. Neither can screenreaders add the control to the list of controls on the page that are of a certain type, e.g. to navigate to all headers of a certain level on the page.
  5. And finally you need to manually style the element in order for it to look distinctive compared to other elements on the page ; using a default control will allow the browser to provide the default style for the platform, which you can still override using CSS if you want.

  Example :

  Compare these two buttons. The first one is implemented using a <div> tag, the second one using a <button> tag. Try using a screenreader to experience the difference.

  Send	<style> .custombutton cursor : pointer ; border : 1px solid #000 ; background-color : #F6F6F6 ; display : inline-block ; padding : 2px 5px ; </style> <div class="custombutton" onclick="alert(’sent !’)"> Send </div>
  Send	<button onclick="alert(’sent !’)"> Send </button>

  2. Make interactive elements keyboard accessible

  Many sophisticated web applications have some interactive controls that just have no appropriate HTML tag equivalent. In this case, you will have had to build an interactive element with JavaScript and <div> and/or <span> tags and lots of custom styling. The good news is, it’s possible to make even these custom controls accessible, and as a side benefit you will also make your application smoother to use for power users.

  The first thing you can do to test usability of your control, or your Web app, is to unplug the mouse and try to use only the [TAB] and [ENTER] keys to interact with your application.

  

  Try the following :

  • Can you reach all interactive elements with [TAB] ?
  • Can you activate interactive elements with [ENTER] (or [SPACE]) ?
  • Are the elements in the right tab order ?
  • After interaction : is the right element in focus ?
  • Is there a keyboard shortcut that activates the element (accesskey) ?

  No ? Let’s fix it.

  2.1. Reaching interactive elements

  If you have an element on your page that cannot be reached with [TAB], put a @tabindex attribute on it.

  Example :

  Here we have a <span> tag that works as a link (don’t do this – it’s just a simple example). The first one cannot be reached using [TAB] but the second one has a tabindex and is thus part of the tab order of the HTML page.

  (Note : since we experiment lots with the tabindex in this article, to avoid confusion, click on some text in this paragraph and then hit the [TAB] key to see where it goes next. The click will set your keyboard focus in the DOM.)

  Click	<style> .customlink text-decoration : underline ; cursor : pointer ; </style> <span class="customlink" onclick="alert(’activated !’)"> Click </span>
  Click	<style> .customlink text-decoration : underline ; cursor : pointer ; </style> <span class="customlink" onclick="alert(’activated !’)" tabindex="0"> Click </span>

  You set @tabindex=0 to add an element into the native tab order of the page, which is the DOM order.

  2.2. Activating interactive elements

  Next, you typically want to be able to use the [ENTER] and [SPACE] keys to activate your custom control. To do so, you will need to implement an onkeydown event handler. Note that the keyCode for [ENTER] is 13 and for [SPACE] is 32.

  Example :

  Let’s add this functionality to the <span> tag from before. Try tabbing to it and hit the [ENTER] or [SPACE] key.

  Click	<span class="customlink" onclick="alert(’activated !’)" tabindex="0"> Click </span>
  &lt;script&gt;<br /> function handlekey(event) {<br /> var target = event.target || event.srcElement;<br /> if (event.keyCode == 13 || event.keyCode == 32) { target.onclick(); }<br /> }<br /> &lt;/script&gt; Click	<span class="customlink" onclick="alert(’activated !’)" tabindex="0" onkeydown="handlekey(event) ;"> Click </span> <script> function handlekey(event) var target = event.target || event.srcElement ; if (event.keyCode == 13 || event.keyCode == 32) target.onclick() ; </script>

  Note that there are some controls that might need support for keys other than [tab] or [enter] to be able to use them from the keyboard alone, for example a custom list box, menu or slider should respond to arrow keys.

  2.3. Elements in the right tab order

  Have you tried tabbing to all the elements on your page that you care about ? If so, check if the order of tab stops seems right. The default order is given by the order in which interactive elements appear in the DOM. For example, if your page’s code has a right column that is coded before the main article, then the links in the right column will receive tab focus first before the links in the main article.

  You could change this by re-ordering your DOM, but oftentimes this is not possible. So, instead give the elements that should be the first ones to receive tab focus a positive @tabindex. The tab access will start at the smallest non-zero @tabindex value. If multiple elements share the same @tabindex value, these controls receive tab focus in DOM order. After that, interactive elements and those with @tabindex=0 will receive tab focus in DOM order.

  Example :

  The one thing that always annoys me the most is if the tab order in forms that I am supposed to fill in is illogical. Here is an example where the first and last name are separated by the address because they are in a table. We could fix it by moving to a <div> based layout, but let’s use @tabindex to demonstrate the change.

  Firstname : Address : Lastname : City :	<table class="customtabs"> <tr> <td>Firstname : <input type="text" id="firstname"> </td> <td>Address : <input type="text" id="address"> </td> </tr> <tr> <td>Lastname : <input type="text" id="lastname"> </td> <td>City : <input type="text" id="city"> </td> </tr> </table>
  Click here to test this form, then [TAB] : Firstname : Address : Lastname : City :	<table class="customtabs"> <tr> <td>Firstname : <input type="text" id="firstname" tabindex="10"> </td> <td>Address : <input type="text" id="address" tabindex="30"> </td> </tr> <tr> <td>Lastname : <input type="text" id="lastname" tabindex="20"> </td> <td>City : <input type="text" id="city" tabindex="40"> </td> </tr> </table>

  Be very careful with using non-zero tabindex values. Since they change the tab order on the page, you may get side effects that you might not have intended, such as having to give other elements on the page a non-zero tabindex value to avoid skipping too many other elements as I would need to do here.

  2.4. Focus on the right element

  Some of the controls that you create may be rather complex and open elements on the page that were previously hidden. This is particularly the case for drop-downs, pop-ups, and menus in general. Oftentimes the hidden element is not defined in the DOM right after the interactive control, such that a [TAB] will not put your keyboard focus on the next element that you are interacting with.

  The solution is to manage your keyboard focus from JavaScript using the .focus() method.

  Example :

  Here is a menu that is declared ahead of the menu button. If you tab onto the button and hit enter, the menu is revealed. But your tab focus is still on the menu button, so your next [TAB] will take you somewhere else. We fix it by setting the focus on the first menu item after opening the menu.

  Menu item1 Menu item2 Menu &lt;script&gt;<br /> function displayMenu(value) {<br /> document.getElementById(&quot;custommenu&quot;).style.display=value;<br /> }<br /> &lt;/script&gt;	<div id="custommenu" style="display:none ;"> <button id="item1" onclick="displayMenu(’none’) ;">Menu item1</button> <button id="item2" onclick="displayMenu(’none’) ;">Menu item2</button> </div> <button onclick="displayMenu(’block’) ;">Menu</button> <script> function displayMenu(value) document.getElementById("custommenu").style.display=value ; </script>
  Menu item1 Menu item2 Menu &lt;script&gt;<br /> function displayMenu2(value) {<br /> document.getElementById(&quot;custommenu2&quot;).style.display=value;<br /> document.getElementById(&quot;item1&quot;).focus();<br /> }<br /> &lt;/script&gt;	<div id="custommenu" style="display:none ;"> <button id="item1" onclick="displayMenu(’none’) ;">Menu item1</button> <button id="item2" onclick="displayMenu(’none’) ;">Menu item2</button> </div> <button onclick="displayMenu(’block’) ;">Menu</button> <script> function displayMenu(value) document.getElementById("custommenu").style.display=value ; document.getElementById("item1").focus() ; </script>

  You will notice that there are still some things you can improve on here. For example, after you close the menu again with one of the menu items, the focus does not move back onto the menu button.

  Also, after opening the menu, you may prefer not to move the focus onto the first menu item but rather just onto the menu <div>. You can do so by giving that div a @tabindex and then calling .focus() on it. If you do not want to make the div part of the normal tabbing order, just give it a @tabindex=-1 value. This will allow your div to receive focus from script, but be exempt from accidental tabbing onto (though usually you just want to use @tabindex=0).

  Bonus : If you want to help keyboard users even more, you can also put outlines on the element that is currently in focus using CSS”s outline property. If you want to avoid the outlines for mouse users, you can dynamically add a class that removes the outline in mouseover events but leaves it for :focus.

  2.5. Provide sensible keyboard shortcuts

  At this stage your application is actually keyboard accessible. Congratulations !

  However, it’s still not very efficient : like power-users, screenreader users love keyboard shortcuts : can you imagine if you were forced to tab through an entire page, or navigate back to a menu tree at the top of the page, to reach each control you were interested in ? And, obviously, anything which makes navigating the app via the keyboard more efficient for screenreader users will benefit all power users as well, like the ubiquitous keyboard shortcuts for cut, copy and paste.

  HTML4 introduced so-called accesskeys for this. In HTML5 @accesskey is now allowed on all elements.

  The @accesskey attribute takes the value of a keyboard key (e.g. @accesskey="x") and is activated through platform- and browser-specific activation keys. For example, on the Mac it’s generally the [Ctrl] key, in IE it’ the [Alt] key, in Firefox on Windows [Shift]-[Alt], and in Opera on Windows [Shift]-[ESC]. You press the activation key and the accesskey together which either activates or focuses the element with the @accesskey attribute.

  Example :

  Send &lt;script&gt;<br /> var button = document.getElementById('accessbutton');<br /> if (button.accessKeyLabel) {<br />  button.innerHTML += ' (' + button.accessKeyLabel + ')';<br /> }<br /> &lt;/script&gt;

  <button id="accessbutton" onclick="alert(’sent !’)" accesskey="e"> Send </button> <script> var button = document.getElementById(’accessbutton’) ; if (button.accessKeyLabel) button.innerHTML += ’ (’ + button.accessKeyLabel + ’)’ ; </script>

  Now, the idea behind this is clever, but the execution is pretty poor. Firstly, the different activation keys between different platforms and browsers make it really hard for people to get used to the accesskeys. Secondly, the key combinations can conflict with browser and screenreader shortcut keys, the first of which will render browser shortcuts unusable and the second will effectively remove the accesskeys.

  In the end it is up to the Web application developer whether to use the accesskey attribute or whether to implement explicit shortcut keys for the application through key event handlers on the window object. In either case, make sure to provide a help list for your shortcut keys.

  Also note that a page with a really good hierarchical heading layout and use of ARIA landmarks can help to eliminate the need for accesskeys to jump around the page, since there are typically default navigations available in screen readers to jump directly to headings, hyperlinks, and ARIA landmarks.

  3. Provide markup for AT

  Having made the application keyboard accessible also has advantages for screenreaders, since they can now reach the controls individually and activate them. So, next we will use a screenreader and close our eyes to find out where we only provide visual cues to understand the necessary interaction.

  Here are some of the issues to consider :

  • Role may need to get identified
  • States may need to be kept track of
  • Properties may need to be made explicit
  • Labels may need to be provided for elements

  This is where the W3C’s ARIA (Accessible Rich Internet Applications) standard comes in. ARIA attributes provide semantic information to screen readers and other AT that is otherwise conveyed only visually.

  Note that using ARIA does not automatically implement the standard widget behavior – you’ll still need to add focus management, keyboard navigation, and change aria attribute values in script.

  3.1. ARIA roles

  After implementing a custom interactive widget, you need to add a @role attribute to indicate what type of controls it is, e.g. that it is playing the role of a standard tag such as a button.

  Example :

  This menu button is implemented as a <div>, but with a role of “button” it is announced as a button by a screenreader.

  Menu	<div tabindex="0" role="button">Menu</div>

  ARIA roles also describe composite controls that do not have a native HTML equivalent.

  Example :

  This menu with menu items is implemented as a set of <div> tags, but with a role of “menu” and “menuitem” items.

  Cut Copy Paste

  <div role="menu"> <div tabindex="0" role="menuitem">Cut</div> <div tabindex="0" role="menuitem">Copy</div> <div tabindex="0" role="menuitem">Paste</div> </div>

  3.2. ARIA states

  Some interactive controls represent different states, e.g. a checkbox can be checked or unchecked, or a menu can be expanded or collapsed.

  Example :

  The following menu has states on the menu items, which are here not just used to give an aural indication through the screenreader, but also a visual one through CSS.

  Left Center Right

  <style> .custombutton[aria-checked=true]:before content : "\2713 " ; </style> <div role="menu"> <div tabindex="0" role="menuitem" aria-checked="true">Left</div> <div tabindex="0" role="menuitem" aria-checked="false">Center</div> <div tabindex="0" role="menuitem" aria-checked="false">Right</div> </div>

  3.3. ARIA properties

  Some of the functionality of interactive controls cannot be captured by the role attribute alone. We have ARIA properties to add features that the screenreader needs to announce, such as aria-label, aria-haspopup, aria-activedescendant, or aria-live.

  Example :

  The following drop-down menu uses aria-haspopup to tell the screenreader that there is a popup hidden behind the menu button together with an ARIA state of aria-expanded to track whether it’s open or closed.

  Justify Left Center Right &lt;script&gt;<br /> var button = document.getElementById(&quot;button&quot;);<br /> var menu = document.getElementById(&quot;menu&quot;);<br /> var items = document.getElementsByClassName(&quot;menuitem&quot;);<br /> var focused = 0;<br /> function showMenu(evt) {<br />    evt.stopPropagation();<br />    menu.style.visibility = 'visible';<br />    button.setAttribute('aria-expanded','true');<br />    focused = getSelected();<br />    items[focused].focus();<br />  }<br />  function hideMenu(evt) {<br />    evt.stopPropagation();<br />    menu.style.visibility = 'hidden';<br />    button.setAttribute('aria-expanded','false');<br />    button.focus();<br />  }<br />  function getSelected() {<br />    for (var i=0; i &lt; items.length; i++) {<br />      if (items[i].getAttribute('aria-checked') == 'true') {<br />        return i;<br />      }<br />    }<br />  }<br />  function setSelected(elem) {<br />    var curSelected = getSelected();<br />    items[curSelected].setAttribute('aria-checked', 'false');<br />    elem.setAttribute('aria-checked', 'true');<br />  }<br />  function selectItem(evt) {<br />    setSelected(evt.target);<br />    hideMenu(evt);<br />  }<br /> function getPrevItem(index) {<br />    var prev = index - 1;<br />    if (prev &lt; 0) {<br />      prev = items.length - 1;<br />    }<br />    return prev;<br />  }<br />  function getNextItem(index) {<br />    var next = index + 1;<br />    if (next == items.length) {<br />      next = 0;<br />    }<br />    return next;<br />  }<br /> function handleButtonKeys(evt) {<br />    evt.stopPropagation();<br />    var key = evt.keyCode;<br />    switch(key) {<br />      case (13): /* ENTER */<br />      case (32): /* SPACE */<br />        showMenu(evt);<br />      default:<br />    }<br />  }<br />  function handleMenuKeys(evt) {<br />    evt.stopPropagation();<br />    var key = evt.keyCode;<br />    switch(key) {<br />      case (38): /* UP */<br />        focused = getPrevItem(focused);<br />        items[focused].focus();<br />        break;<br />      case (40): /* DOWN */<br />        focused = getNextItem(focused);<br />        items[focused].focus();<br />        break;<br />      case (13): /* ENTER */<br />      case (32): /* SPACE */<br />        setSelected(evt.target);<br />          hideMenu(evt);<br />          break;<br />      case (27): /* ESC */<br />        hideMenu(evt);<br />         break;<br />      default:<br />    }<br />  }<br />  button.addEventListener('click', showMenu, false);<br />  button.addEventListener('keydown', handleButtonKeys, false);<br />  for (var i = 0;  i &lt; items.length; i++) {<br />    items[i].addEventListener('click', selectItem, false);<br />    items[i].addEventListener('keydown', handleMenuKeys, false);<br />  }<br /> &lt;/script&gt;

  <div class="custombutton" id="button" tabindex="0" role="button" aria-expanded="false" aria-haspopup="true"> <span>Justify</span> </div> <div role="menu" class="menu" id="menu" style="display : none ;"> <div tabindex="0" role="menuitem" class="menuitem" aria-checked="true"> Left </div> <div tabindex="0" role="menuitem" class="menuitem" aria-checked="false"> Center </div> <div tabindex="0" role="menuitem" class="menuitem" aria-checked="false"> Right </div> </div> [CSS and JavaScript for example omitted]

  3.4. Labelling

  The main issue that people know about accessibility seems to be that they have to put alt text onto images. This is only one means to provide labels to screenreaders for page content. Labels are short informative pieces of text that provide a name to a control.

  There are actually several ways of providing labels for controls :

  • on img elements use @alt
  • on input elements use the label element
  • use @aria-labelledby if there is another element that contains the label
  • use @title if you also want a label to be used as a tooltip
  • otherwise use @aria-label

  I’ll provide examples for the first two use cases - the other use cases are simple to deduce.

  Example :

  The following two images show the rough concept for providing alt text for images : images that provide information should be transcribed, images that are just decorative should receive an empty @alt attribute.

  Image by Noah Sussman

  <img src="texture.jpg" alt=""> <img src="lolcat.jpg" alt="shocked lolcat titled ’HTML cannot do that !"> <img src="texture.jpg" alt="">

  When marking up decorative images with an empty @alt attribute, the image is actually completely removed from the accessibility tree and does not confuse the blind user. This is a desired effect, so do remember to mark up all your images with @alt attributes, even those that don’t contain anything of interest to AT.

  Example :

  In the example form above in Section 2.3, when tabbing directly on the input elements, the screen reader will only say "edit text" without announcing what meaning that text has. That’s not very useful. So let’s introduce a label element for the input elements. We’ll also add checkboxes with a label.

  Doctor title : Firstname : Lastname : Address : City : Remember me :

  <label>Doctor title :</label> <input type="checkbox" id="doctor"/> <label>Firstname :</label> <input type="text" id="firstname2"/> <label for="lastname2">Lastname :</label> <input type="text" id="lastname2"/> <label>Address : <input type="text" id="address2"> </label> <label for="city2">City : <input type="text" id="city2"> </label> <label for="remember">Remember me :</label> <input type="checkbox" id="remember">

  In this example we use several different approaches to show what a different it makes to use the <label> element to mark up input boxes.

  The first two fields just have a <label> element next to a <input> element. When using a screenreader you will not notice a difference between this and not using the <label> element because there is no connection between the <label> and the <input> element.

  In the third field we use the @for attribute to create that link. Now the input field isn’t just announced as "edit text", but rather as "Lastname edit text", which is much more useful. Also, the screenreader can now skip the labels and get straight on the input element.

  In the fourth and fifth field we actually encapsulate the <input> element inside the <label> element, thus avoiding the need for a @for attribute, though it doesn’t hurt to explicity add it.

  Finally we look at the checkbox. By including a referenced <label> element with the checkbox, we change the screenreaders announcement from just "checkbox not checked" to "Remember me checkbox not checked". Also notice that the click target now includes the label, making the checkbox not only more usable to screenreaders, but also for mouse users.

  4. Conclusions

  This article introduced a process that you can follow to make your Web applications accessible. As you do that, you will noticed that there are other things that you may need to do in order to give the best experience to a power user on a keyboard, a blind user using a screenreader, or a vision-impaired user using a screen magnifier. But once you’ve made a start, you will notice that it’s not all black magic and a lot can be achieved with just a little markup.

  You will find more markup in the WAI ARIA specification and many more resources at Mozilla’s ARIA portal. Now go and change the world !

  Many thanks to Alice Boxhall and Dominic Mazzoni for their proof-reading and suggested changes that really helped improve the article !

• My SBC Collection

  31 décembre 2023, par Multimedia Mike — General

  Like many computer nerds in the last decade, I have accumulated more than a few single-board computers, or “SBCs”, which are small computers based around a system-on-a-chip (SoC) that nearly always features an ARM CPU at its core. Surprisingly few of these units are Raspberry Pi units, though that brand has come to exemplify and dominate the product category.

  Also, as is the case for many computer nerds, most of these SBCs lay fallow for years at a time. Equipped with an inexpensive lightbox that I procured in the last year, I decided I could at least create glamour shots of various units and catalog them in a blog post.

  While Raspberry Pi still enjoys the most mindshare far and away, and while I do have a few Raspberry Pi units in my inventory, I have always been a bigger fan of the ODROID brand, which works with convenient importers around the world (in the USA, I can vouch for Ameridroid, to whom I’ve forked over a fair amount of cash for these computing toys).

  As mentioned, Raspberry Pi undisputedly has the most mindshare of all these SBC brands and I often wonder why… and then I immediately remind myself that it has the biggest ecosystem, and has a variety of turnkey projects and applications (such as Pi-hole and PiVPN) that promise a lower barrier to entry — as well as a slightly lower price point — than some of these other options. ODROID had a decent ecosystem for awhile, especially considering the monthly ODROID Magazine, though that ceased publication in July 2020. The Raspberry Pi and its variants were famously difficult to come by due to the global chip shortage from 2021-2023. Meanwhile, I had no trouble procuring these boards during the same timeframe.

  So let’s delve into the collection…
  

  Cubieboard
  The Raspberry Pi came out in 2012 and by 2013 I was somewhat coveting one to hack on. Finally ! An accessible ARM platform to play with. I had heard of the BeagleBoard for years but never tried to get my hands on one. I was thinking about taking the plunge on a new Raspberry Pi, but a colleague told me I should skip that and go with this new hotness called the Cubieboard, based on an Allwinner SoC. The big value-add that this board had vs. a Raspberry Pi was that it had a SATA adapter. Although now that it has been a decade, it only now occurs to me to quander whether it was true SATA or a USB-to-SATA bridge. Looking it up now, I’m led to believe that the SoC supported the functionality natively.

  Anyway, I did get it up and running but never did much with it, thus setting the tone for future SBC endeavors. No photos because I gave it to another tech enthusiast years ago, whose SBC collection dwarfs my own.

  ODROID-XU4
  I can’t recall exactly when or how I first encountered the ODROID brand. I probably read about it on some enthusiast page or another circa 2014 and decided to try one out. I eventually acquired a total of 3 of these ODROID-XU4 units, each with a different case, 1 with a fan and 2 passively-cooled :

  

  Collection of ODROID-XU4 SBCs

  This is based on the Samsung Exynos 5422 SoC, the same series as was used in their Note 3 phone released in 2013. It has been a fun chip to play with. The XU4 was also my first introduction to the eMMC storage solution that is commonly supported on the ODROID SBCs (alongside micro-SD). eMMC offers many benefits over SD in terms of read/write speed as well as well as longevity/write cycles. That’s getting less relevant these days, however, as more and more SBCs are being released with direct NVMe SSD support.

  I had initially wanted to make a retro-gaming device built on this platform (see the handheld section later for more meditations on that). In support of this common hobbyist goal, there is this nifty case XU4 case which apes the aesthetic of the Nintendo N64 :

  

  ODROID-XU4 N64-style case

  It even has a cool programmable LCD screen. Maybe one day I’ll find a use for it.

  For awhile, one of these XU4 units (likely the noisy, fan-cooled one) was contributing results to the FFmpeg FATE system.

  While it features gigabit ethernet and a USB3 port, I once tried to see if I could get 2 Gbps throughput with the unit using a USB3-gigabit dongle. I had curious results in that the total amount of traffic throughput could never exceed 1 Gbps across both interfaces. I.e., if 1 interface was dealing with 1 Gbps and the other interface tried to run at 1 Gbps, they would both only run at 500 Mbps. That remains a mystery to me since I don’t see that limitation with Intel chips.

  Still, the XU4 has been useful for a variety of projects and prototyping over the years.

  ODROID-HC2 NAS
  I find that a lot of my fellow nerds massively overengineer their homelab NAS setups. I’ll explore this in a future post. For my part, people tend to find my homelab NAS solution slightly underengineered. This is the ODROID-HC2 (the “HC” stands for “Home Cloud”) :

  

  ODROID-HC2 NAS

  It has the same guts as the ODROID-XU4 except no video output and the USB3 function is leveraged for a SATA bridge. This allows you to plug a SATA hard drive directly into the unit :

  

  ODROID-HC2 NAS uncovered

  Believe it or not, this has been my home NAS solution for something like 6 or 7 years now– I don’t clearly remember when I purchased it and put it into service.

  But isn’t this sort of irresponsible ? What about a failure of the main drive ? That’s why I have an external drive connected for backing up the most important data via rsync :

  

  ODROID-HC2 NAS backup enclosure

  The power consumption can’t be beat– Profiling for a few weeks of average usage worked out to 4.5 kWh for the ODROID-HC2… per month.

  ODROID-C2
  I was on a kick of ordering more SBCs at one point. This is the ODROID-C2, equipped with a 64-bit Amlogic SoC :

  

  ODROID-C2

  I had this on the FATE farm for awhile, performing 64-bit ARM builds (vs. the XU4’s 32-bit builds). As memory serves, it was unreliable and would occasionally freeze up.

  Here is a view of the eMMC storage through the bottom of the translucent case :

  

  Bottom of ODROID-C2 with view of eMMC storage

  ODROID-N2+
  Out of all my ODROID SBCs, this is the unit that I long to “get back to” the most– the ODROID-N2+ :

  

  ODROID-N2+

  Very capable unit that makes a great little desktop. I have some projects I want to develop using it so that it will force me to have a focused development environment.

  Raspberry Pi
  Eventually, I did break down and get a Raspberry Pi. I had a specific purpose in mind and, much to my surprise, I have stuck to it :

  

  Original Raspberry Pi

  I was using one of the ODROID-XU4 units as a VPN gateway. Eventually, I wanted to convert the XU4 to something else and I decided to run the VPN gateway as an appliance on the simplest device I could. So I procured this complete hand-me-down unit from eBay and went to work. This was also the first time I discovered the DietPi distribution and this box has been in service running Wireguard via PiVPN for many years.

  I also have a Raspberry Pi 3B+ kicking around somewhere. I used it as a Steam Link device for awhile.

  SOPINE + Baseboard
  Also procured when I was on this “let’s buy random SBCs” kick. The Pine64 SOPINE is actually a compute module that comes in the form factor of a memory module.

  

  Pine64 SOPINE Compute Module

  Back to using Allwinner SoCs. In order to make this thing useful, you need to place it in something. It’s possible to get a mini-ITX form factor board that can accommodate 7 of these modules. Before going to that extreme, there is this much simpler baseboard which can also use eMMC for storage.

  

  Baseboard with SOPINE, eMMC, and heat sinks

  I really need to find an appropriate case for this one as it currently performs its duty while sitting on an anti-static bag.

  NanoPi NEO3
  I enjoy running the DietPi distribution on many of these SBCs (as it’s developed not just for Raspberry Pi). I have also found their website to be a useful resource for discovering new SBCs. That’s how I found the NanoPi series and zeroed in on this NEO3 unit, sporting a Rockchip SoC, and photographed here with some American currency in order to illustrate its relative size :

  

  NanoPi NEO3

  I often forget about this computer because it’s off in another room, just quietly performing its assigned duty.

  MangoPi MQ-Pro
  So far, I’ve heard of these fruits prepending the Greek letter pi for naming small computing products :

  • Raspberry – the O.G.
  • Banana – seems to be popular for hobbyist router/switches
  • Orange
  • Atomic
  • Nano
  • Mango

  Okay, so the AtomicPi and NanoPi names don’t really make sense considering the fruit convention.

  Anyway, the newest entry is the MangoPi. These showed up on Ameridroid a few months ago. There are 2 variants : the MQ-Pro and the MQ-Quad. I picked one and rolled with it.

  

  MangoPi MQ-Pro pieces arrive

  When it arrived, I unpacked it, assembled the pieces, downloaded a distro, tossed that on a micro-SD card, connected a monitor and keyboard to it via its USB-C port, got the distro up and running, configured the wireless networking with a static IP address and installed sshd, and it was ready to go as a headless server for an edge application.

  

  MangoPi MQ-Pro components, ready for assembly

  The unit came with no instructions that I can recall. After I got it set up, I remember thinking, “What is wrong with me ? Why is it that I just know how to do all of this without any documentation ?”

  

  MangoPi MQ-Pro in first test

  Only after I got it up and running and poked around a bit did I realize that this SBC doesn’t have an ARM SoC– it’s a RISC-V SoC. It uses the Allwinner D1, so it looks like I came full circle back to Allwinner.

  

  MangoPi MQ-Pro with more US coinage for scale

  So I now have my first piece of RISC-V hobbyist kit, although I learned recently from Kostya that it’s not that great for multimedia.

  Handheld Gaming Units
  The folks at Hardkernel have also produced a series of handheld retro-gaming devices called ODROID-GO. The first one resembled the original Nintendo Game Boy, came as a kit to be assembled, and emulated 5 classic consoles. It also had some hackability to it. Quite a cool little device, and inexpensive too. I have since passed it along to another gaming enthusiast.

  Later came the ODROID-GO Advance, also a kit, but emulating more devices. I was extremely eager to get my hands on this since it could emulate SNES in addition to NES. It also features a headphone jack, unlike the earlier model. True to form, after I received mine, it took me about 13 months before I got around to assembling it. After that, the biggest challenge I had was trying to find an appropriate case for it.

  

  ODROID-GO Advance with case and headphones

  Even though it may try to copy the general aesthetic and form factor of the Game Boy Advance, cases for the GBA don’t fit this correctly.

  Further, Hardkernel have also released the ODROID-GO Super and Ultra models that do more and more. The Advance, Super, and Ultra models have powerful SoCs and feature much more hackability than the first ODROID-GO model.

  I know that the guts of the Advance have been used in other products as well. The same is likely true for the Super and Ultra.

  Ultimately, the ODROID-GO Advance was just another project I assembled and then set aside since I like the idea of playing old games much more than actually doing it. Plus, the fact has finally crystalized in my mind over the past few years that I have never enjoyed handheld gaming and likely will never enjoy handheld gaming, even after I started wearing glasses. Not that I’m averse to old Game Boy / Color / Advance games, but if I’m going to play them, I’d rather emulate them on a large display.

  The Future
  In some of my weaker moments, I consider ordering up certain Banana Pi products (like the Banana Pi BPI-R2) with a case and doing my own router tricks using some open source router/firewall solution. And then I remind myself that my existing prosumer-type home router is doing just fine. But maybe one day…

  The post My SBC Collection first appeared on Breaking Eggs And Making Omelettes.

• 5-Step Conversion Rate Optimisation Checklist

  27 octobre 2023, par Erin

  Did you know the average conversion rate across e-commerce businesses in August 2023 was 2.03% ? In the past year, conversion rates have increased by 0.39%.

  Make no mistake. Just because conversion rates are higher this year doesn’t make it any easier to convert visitors.

  Cracking the secrets to improving conversion rates is crucial to running a successful website or business.

  Your site is the digital headquarters all of your marketing efforts funnel toward. With every visitor comes an opportunity to convert them into a lead (or sale).

  Keep reading if you want to improve your lead generation or convert more visitors into customers. In this article, we’ll break down a simple five-step conversion rate optimisation checklist you need to follow to maximise your conversions.

  What is conversion rate optimisation ?

  Before we dive into the steps you need to follow to optimise your conversions, let’s back up and talk conversion rate optimisation.

  

  Conversion rate optimisation, or CRO for short, is the process of increasing the number of website visitors who take a specific action. 

  In most cases, this means :

  • Turning more visitors into leads by getting them to join an email list
  • Convincing a visitor to fill out a contact form for a consultation
  • Converting a visitor into a paying customer by purchasing a product

  However, conversion rate optimisation can be used for any action you want someone to take on your site. That could be downloading a free guide, clicking on a specific link, commenting on a blog post or sharing your website with a friend.

  Why following a CRO checklist is important

  Conversion rate optimisation is both a valuable practice and an absolute necessity for any business or marketer. While it can be a bit complex, especially when you start diving into A/B testing, there are a variety of advantages :

  Get the most out of your efforts

  When all is said and done, if you can’t convert the traffic already coming to your site, dumping a ton of time and resources into traffic generation (whether paid or organic) won’t solve your problem.

  Instead, you need to look at the root of the problem : your conversion rate.

  By doubling down on conversions and following a conversion rate optimisation checklist, you’ll get the greatest result for the effort you’re already putting into your site.

  Increase audience size

  To increase your audience size, you need to increase your traffic, right ? Not exactly.

  While your audience may be considered people who have seen your content or follow you on social media, a high-value audience is one you can market to directly on an ongoing basis.

  Your website gives you the playground to convert visitors into high-value audience members. This is done by creating conversion-focused email signup forms and optimising your website for sale conversions.

  Generate more sales

  Boosting sales through CRO is the core objective. By optimising product pages, simplifying the checkout process, and employing persuasive strategies, you can systematically increase your sales and maximise the value of your existing traffic.

  Reduce customer acquisition costs (CAC)

  With conversion optimisation, you can convert a higher percentage of your website visitors into paid customers. Even if you don’t spend more on acquiring new customers, you’ll be able to generate more sales overall. 

  The result is that your customer acquisition costs will drop, allowing you to increase your total acquisitions to your customer base.

  Improve profitability

  While reduced customer acquisition costs mean you can pour more money into customer acquisition at a cheaper rate, you could simply maintain your costs while driving sales, resulting in increased profitability.

  If you can spend the same amount on acquisition but bring in 20% more customers (due to using a CRO checklist), your profit margins will automatically increase.

  5-step CRO checklist

  To double down on conversion rate optimisation, you need to follow a checklist to ensure you don’t miss any major optimisation opportunities.

  The checklist below is designed to help you systematically optimise your website, ensuring you make the most of your traffic by continuously refining its performance.

  1. Forms

  Analysing and optimising your website’s forms is crucial for enhancing conversion rates. Understanding how visitors interact with your forms can uncover pain points and help you streamline the conversion process.

  Ever wonder where your visitors drop off on your forms ? It could be due to lengthy, time-consuming fields or overly complex forms, leading to a frustrating user experience and lower conversion rate. Whatever the reason, you need the right tools to uncover the root of the issue.

  By leveraging Form Analytics, you gain powerful insights into user behaviour and can identify areas where people may encounter difficulties.

  Form Analytics provides the insights to discover :

  • Average time spent on each field : This metric helps you understand where users may be struggling or spending too much time. By optimising these fields, you can streamline the form, reduce user frustration and increase conversions.
  • Identifying drop-off points : Understanding where users drop off provides insights into which form fields may need improvement. Addressing these drop-off points can increase the conversion rate.
  • Unneeded fields with a high blank submission rate : Discovering fields left blank upon submission can highlight areas for simplification. By eliminating unnecessary fields, you can create more concise and user-friendly forms that may entice more visitors to engage with the form.

  

  Hear first-hand how Concrete CMS achieve 3x more leads with insights from Form Analytics. 

  These data-driven insights empower you to optimise your forms, remove guesswork and settle debates about form design. By fine-tuning and streamlining your forms, you can ensure a smoother path to conversion and maximise your success in converting more visitors.

  Try Matomo for Free

  Get the web insights you need, without compromising data accuracy.

  Start for free

  No credit card required

  2. Copywriting

  Another crucial element you need to test is your copywriting. Your copywriting is the foundation of your entire website. It helps communicate to your audience what you have to offer and why they need to take action.

  You need to ensure you have a good offer. This isn’t just the product or service you’re putting out there. It’s the complete package. It includes the product, rewards, a unique guarantee, customer service, packaging and promotions.

  Start testing your copy with your headlines. Look at the headers and test different phrases to convert more potential customers into paying customers.

  Here are a few tips to optimise your copy for more conversions :

  • Ensure copy is relevant to your headline and vice versa.
  • Write short words, short sentences and short paragraphs.
  • Use bullets and subheaders to make the copy easy to skim.
  • Don’t focus too heavily on optimising for search engines (SEO). Instead, write for humans.
  • Focus on writing about benefits, not features.
  • Write about how your offer solves the pain points of your audience.

  You can test your copy in several areas once you’ve begun testing your headers – your subheaders, body copy, signup forms and product pages (if you’re e-commerce).

  3. Media : videos and audio

  Next, testing out different media types is crucial. This means incorporating videos and audio into your content.

  Don’t just take a random guess by throwing stuff against the wall, hoping it sticks. Instead, you should use data to develop impactful content.

  Look at your Media Analytics reports in your website analytics solution and see what media people spend the most time on. See what kind of video or audio content already impacts conversions.

  

  Humans are highly visual. You should craft your content so it’s easy to digest. Instead of covering your website in huge chunks of text, split up your copy with engaging content like videos.

  High-quality videos and audio recordings allow your readers to consume more of your content easily, and help persuade them to take action on your site.

  4. Calls to action (CTA)

  This brings us to our next point : your call to action (CTA).

  Are you trying to convert more prospects into leads ? Want to turn more leads into customers ? Trying to get more email subscribers ? Or do you want to generate more sales every month ?

  You could write the most compelling offer flooded with beautiful images, videos and CRO tactics. But your efforts will go to waste if you don’t include a compelling CTA.

  

  Here are a few tips to optimise your CTAs :

  • Keep them congruent on a single web page (e.g., don’t sell a hat and a sweater on the same page, as it can be confusing).
  • Place at least one CTA above the fold on your web pages.
  • Include benefits in your CTA. Rather than “Buy Now,” try “Buy Now to Get 30% Off.”
  • It’s better to be clear and concise than too fancy and unique.

  Optimising your call to action isn’t just about your copywriting. It’s also about design. Test different fonts, sizes, and visual elements like borders, icons and background colours.

  5. Web design

  Your site design will impact how well your visitors convert. You could have incredible copywriting, but if your site is laid out poorly, it will drive people away.

  You must ensure your copy and visual content fit your website design well.

  The first place you need to start with your site is your homepage design.

  Your site design consists of the theme or template, colour scheme and other visual elements that can be optimised to improve conversions.

  Here are a few tips to keep in mind when optimising your website design :

  • Use a colour scheme that’s pleasant rather than too distracting or extreme.
  • Ensure your design doesn’t remove the text’s clarity but makes it easier to read.
  • When in doubt, start with black text on a white background (the opposite rarely works).
  • Keep plenty of whitespace in between design elements.
  • When in doubt about font size, start by testing a larger size.
  • Design mobile-first rather than desktop-first.

  Finally, it’s critical to ensure your website is easy to navigate. Good design is all about the user experience. Is it easy to find what they’re looking for ? Simplify steps to reduce the need to click, and your conversions will increase.

  Start optimising your website for conversions

  If you’re looking to get the most out of the traffic on your site by converting more visitors into leads or customers, following this 5-step CRO checklist will help you take steps in the right direction.

  Just remember conversion rate optimisation is an ongoing process. It’s not a one-time deal. To succeed, you need to test quickly, analyse the impact and do more of what’s working and less of what’s not.

  To optimise your website for better conversion rates, you need the right tools that provide accurate data and insights to effectively increase conversions. With Matomo, you gain access to web analytics and CRO features like Form Analytics and Media Analytics, designed to enhance your conversion rate optimisation efforts. 

  Try Matomo free for 21 days and take your conversion rate to the next level. No credit card required.

  Try Matomo for Free

  21 day free trial. No credit card required.

  
  

  Your email address
  

  Your website address
  

  Your Analytics subdomain will be .matomo.cloud (change)

  Choose your analytics subdomain
  

  .matomo.cloud

  I accept the terms and conditions and data processing agreement (DPA)

  
  Your information will be used to create an account on our cloud service. For more information please consult our privacy policy.
  
  
  

  Start improving your websites now