Designing Accessibility Into Themes

Because she is amazing, Ann McMeekin has prepared for us a guide to designing accessibility into themes – it’s useful far beyond this project so we’re sharing it here and pls feel free to pass it on to other who might find it useful. You can download a PDF version of this document here.

Before You Begin

  • Do some research. If you don’t understand what accessibility is, or how people with disabilities use computers, take some time to do some research. is a good place to start, and some videos of people with disabilities using the web can be found at
  • Ask an expert. If you need help, ask an expert. If you don’t know any, you can find lots of helpful and knowledgeable people at
  • Accessibility isn’t just about sight loss. Although we usually associate accessibility issues with people who have sight loss, many other people encounter difficulties when trying to use websites. The needs of those with hearing impairments, mobility difficulties, and cognitive impairments or any combination of the above are just as important.
  • Aim for a good experience regardless of ability or technology. Listening to a site is a very different experience from seeing a site but, with careful implementation, both can be a good experience. Where a drag and drop interface might be great for those who can use a mouse, the equivalent experience for keyboard only users would be something equally easy to understand and use.
  • Include accessibility in the design. Accessibility is better for users, easier to implement, and less likely to have an adverse impact on the visual design if it is included in the design process rather than being implemented at the end.

Structure and Markup

  • Use appropriate markup. Lists are lists, headings are headings, and quotations deserve appropriate markup, too. Paying careful attention to web standards automatically increases the accessibility of any page we create.
  • Avoid using structural markup for presentation. The H1-H6 elements are for providing structure not altering text size and blockquote elements are for distinguishing quotations not indenting text.
  • Avoid using unconventional markup. At best, unconventional markup can be confusing for users, at worst, it can make pages difficult or impossible to use. For example, don’t use form elements instead of lists for navigation, and don’t use links instead of buttons for form submission.
  • Use the <title> element effectively. Putting the information in the form you’d use for a reverse breadcrumb trail (e.g., [page] – [section] – [site name]) places unique information first and means less repetitive reading for users.
  • Specify the natural language of the document. This ensures that browsers display characters properly and screen readers use the correct pronunciation rules. For English in HTML add lang=”en” to your <html> element. For XHTML1.0, change your <html> element to <html xmlns=”” lang=”en” xml:lang=”en”>. Language codes can be found at
  • Specify any changes in the natural language. If you change language midway through a page and don’t markup the change correctly, the screen reader will read the second language as if it was the first. The lang attribute can be added to any element. The span element can be used within a containing element or a div can be used if the change includes multiple elements. For example <p lang=”fr”>Bonjour</p>, <p><span lang=”es”>Hasta la vista</span>, baby</p> or <div lang=”la”><p>Lorem ipsum…</p><p>Etiam in risus ipsum…</p></div>.
  • Use lists for navigation. This allows screen reader users to build a mental model of the size of the site/navigation without having to listen to and count each item in the menu.
  • Use the most appropriate source code order for the type of site. Designing a page structure based on user needs allows us to provide a better experience for our users. Putting navigation before content works well for sites where users browse before reading, but putting the content first may be more appropriate for blogs and other content-rich sites where readers are more likely to read first and then browse for other content.
  • Use skip links to provide keyboard shortcuts to content or navigation. Ideally, skip links should be visible by default, because they are especially useful to those who have mobility difficulties or do not use specialized accessibility software. However, having them appear when the links receive focus is acceptable, if they are placed sensibly. To be most useful, they should be kept to a minimum (no more than three) and be the first links in the source code order. The link text should ideally describe the destination, for example “Skip to main content” or “Skip to main navigation,” rather than “Skip navigation.”
  • Create a logical page structure. Check the page without CSS. It should still have a logical structure and be easy to navigate and understand.
  • Use headings appropriately, including section headings if necessary. <h1> is used for main heading of each page (which is not always the site name). Any subheadings (including section headings) of <h1> are <h2>, and so on. Using this type of heading structure allows screen reader users to create a mental model of the page, quickly determine if it contains the information they seek, and then navigate directly to the section they want.
  • Write good link text. Link text should contain all important information, be concise, be unique, and make sense when read out of context. “Terms and Conditions (PDF 30kb)” is good. “Click here” is not.
  • Notify users of popups and new windows. In general, use of pop-ups and new windows should be avoided in favor of allowing users to choose the desired behavior. However, if the use of a popup or a new window is unavoidable, the user should be notified within the link text. This can be done by including the words “(new window)” or “(pop-up)” in the link text or inserting an appropriate icon and giving it appropriate alt text.
  • Avoid CAPTCHAs if at all possible. If their use is unavoidable, provide an audio alternative (e.g., and a mechanism for users to get timely support if they need it, for example, an email address or telephone number.

Data Tables

  • Specify table headers. Row and column headings should be marked up using the <th> element and scope=”row” or scope=”col” attributes as appropriate.
  • Associate headers with cells. If more than one level of heading is required, give each header cell a unique id (e.g., <th id=”id1”>) and use the headers attribute to explicitly associate the cell and its headers. Each heading id should be referenced, in order, within the headers attribute, for example <td headers=”id1 id2”>. This ensures that the headers are read out to screen reader users in the correct order.
  • Describe the purpose of the table. Use the caption element to provide a visual description which concisely describes what information is being provided. For example, using “June 2009” for a calendar.Describe the structure of the data. Use the summary element to provide a concise description of the data structure of the table. Using the calendar example, the summary could be “Columns contain days of the week from left to right, starting on Sunday.”


  • Place important information/instructions at the top of the form. Providing instructions first reduces user error and provides a better user experience.
  • Always indicate required fields. In addition, inform users at the beginning of the form how required fields will be indicated. The convention is to use a red asterisk, but this can also be provided by a small icon accompanied by alt text that says “required”.
  • Ensure all form fields have a label and explicitly associate it using the for attribute. Explicit association allows screen readers to announce the correct label, and moves the focus to the associated element when the label text is clicked. If there is absolutely no room for a visible label, the label may be moved offscreen using {position: absolute; top: -999em} in CSS, or the title attribute used instead.
  • Place labels close to their associated element. Too much white space between label and element can mean that screen magnification users cannot see the label along with the field, which may lead to increased errors when completing the form.
  • Include the required field indicator within the label element. If this is placed after or below the form field, it may be missed by those who use screen reader or screen magnification software.
  • Place help text between the label and the form field. If guidance is needed to enable users to complete the field correctly, it should be provided before the relevant field, not after.
  • Allow users to hide/show help text. This allows users to control how much information they are presented with and cuts down on visual or auditory “clutter” for frequent users.
  • Group form controls and label them appropriately. Use a fieldset with an appropriate legend to provide context for groups of radio buttons or checkboxes.
  • Write legend text with care. Be aware when writing legend text that screen readers read the legend and label text for each item enclosed within the fieldset. Try to ensure that each label makes sense when read together with the legend, as well as on its own. A great example of this can be found at where a fieldset legend of “Search” combines well with radio button labels of “the web”, “for images”, “for video”, and “for audio”.
  • Segment lengthy forms. When working with lengthy forms, consider splitting them into multiple pages or using headings in addition to fieldsets with legends. In this case, headings can be worded slightly differently to the legend to minimise repetition and hidden offscreen using CSS.
  • Summarize errors at the top of the form. This provides an overview of all action required to complete the form correctly. It is also beneficial to provide anchor links to fields which require attention.Highlight fields with errors clearly. This could be accomplished by using an icon at the beginning of the label with alt text of “error: [concise description of error]”.
  • Allow users to confirm or undo important actions. This helps increase user confidence and reduce errors.

Interactivity, JavaScript and Rich Internet Applications

  • Build a solid base. Design the base experience to be a great one before jumping into dynamic interactions. This ensures that the users who cannot access or use the rich experience do not feel deprived.
  • Be aware that screen readers parse JavaScript. Many modern screen readers have some level of support for JavaScript and care should be taken to ensure that its use does not cause pages to become less accessible.
  • Be careful when implementing functionality that changes areas of the page without refreshing the page, such as AJAX. Screen reader software works by taking a virtual copy of the page, which it then interrogates. If the page changes without a refresh (or some indication that the user should refresh their virtual copy) users may be unaware that content has changed.
  • Research best practice techniques before implementing rich interactions and functionality. As this is a relatively new area, techniques are continually being developed and improved and support for rich interactions is increasing. The Paciello Group is doing great work in this area and documenting it at
  • Understand the impact of the desired functionality. It is better to exercise caution when considering the use of new techniques or functionality. If, following research, it is not possible to implement the desired functionality in an accessible manner, consider using an alternative until an accessible solution is found.


  • Specify background with text color. When specifying any text color, be sure to also specify a default body background color.Check color combinations for sufficient contrast. Check all background/text color combinations to ensure that they meet WCAG2.0 guidelines A great tool for this is the The Paciello Group Color Contrast Analyzer .
  • Check that readability is maintained when using patterned backgrounds. Ensure that text maintains a suitable contrast ratio against any textured or patterned background. This can be done by using a strip of solid color between the text and the background pattern to separate the text from the background and maintain readability.
  • Don’t rely on color alone to provide meaning or understanding. For example, don’t refer to colored text or change the text to red to indicate an error. Provide some other method such as underlining, adding a border or outline, or adding an icon with appropriate alt text


  • Provide alt attributes for every image. Every image placed in HTML must have an alt attribute which contains a concise, appropriate alternative.
    • For linked images, the alt text should describe the destination of the link.
    • For decorative images, the alt text should be null (alt=””) or empty (alt=” “) which lets assistive technology know that the image can safely be ignored. Alternatively, these images can be presented as CSS background images.
    • For images of text, the alt text should duplicate the text within the image.
    • For images which contain information, or are important content, the alt text should be a concise description of the purpose of the image. A good way to identify this kind of image is to imagine reading the page to someone over the telephone. If the image is not important enough to be described, it can be considered decorative and treated appropriately.
    • If the image is a graph or diagram, the alt text should be a concise description of what the graph is (e.g., “Sales figures for June 2009”,) accompanied by a longer description or alternative displayed adjacent to the image or provided on a separate but clearly linked page.
  • Avoid using CSS to display images which contain information. It is better to treat the image as content, display it using the img element and provide an appropriate alternative.
  • Ensure text contrast is maintained if a background image is not displayed. Specify a background colour in addition to the background image to avoid text becoming unreadable if the background image is not displayed for any reason.Use images to enhance understanding. This can help those whose main language is not the same as the language used on the site, and also those who have difficulty understanding text. For example, a question mark icon could be added next to the word “Help”.Combine adjacent image and text links. Combining adjacent links where an image and text have the same destination reduces repetition for screen reader users. Ensure the image alt and link text make sense when read together, leaving the image alt null if the alt text would otherwise duplicate the adjacent link text. A link to a downloadable document could be written as <a href=”url”>Annual Report 2009 <img src=”pdf.jpg” alt=”PDF”> 400kb)</a> or an email link could be written as <a href=”mailto:address”><img src=”email.jpg” alt=”” />email us</a>.


  • Use relative units. Base text sizes from a default of at least 100% or 1em. If absolute units must be used, provide a separate stylesheet for Internet Explorer that specifies sizes in percentages or ems to ensure those users can resize text if they need to.
  • Maintain readability when text size is decreased as well as increased. In general, avoid specifying text smaller than 75% or 0.75em, but if smaller text is required, ensure it remains readable at two steps smaller than default. This helps users with tunnel vision who may reduce the text size in order to reduce eye strain when reading on screen.
  • Consider making small text bold. This can improve contrast and readability.
  • Increase line-height to improve readability. Using a line-height of slightly larger than normal (e.g., 1.2 to 1.6) can prevent ascending and descending characters from “crashing together” making text easier to read for everyone, but those with dyslexia or other reading impairments in particular.
  • Avoid fully justified text. This can create “rivers” of whitespace and cause significant difficulty to dyslexic users.
  • Use appropriate case. Screen readers use different pronunciation rules for text in ALL-CAPS. For example, “CONTACT US” would be pronounced “contact U S” rather than “contact us”, which could cause confusion. Avoid this by using the appropriate case in the source and using text-transform in CSS to change the visual display if required.
  • Limit use of images of text. If images of text or image replacement techniques are required, limit their use to only the main heading of a page. This helps users who require specific colour schemes, preventing them from having to make further changes to their browser settings in order to read the page.
  • Make images of text clear and easy to read. If images of text are unavoidable, ensure that the text size is reasonably large (above 18px) and has good contrast. This helps people who use screen magnification software, as small images of text will pixelate when magnified and may become impossible to read.

Orientation and Way-finding

  • Provide focus states as well as hover states for links. Ensure that any changes which happen on hover also occur on focus to help keyboard only users identify the focused element.
  • Identify the current location in navigation. Using a different visual style to identify the current section or page within navigation can helps users to quickly orient themselves within the site.
  • Do not remove the default browser focus outline. The focus outline is vitally important to users who have mobility difficulties and navigate through the site without using a mouse. If the default focus outline seems insufficient, it can be enhanced using CSS.
  • Do not move links out of the viewport using CSS. If links are moved offscreen, keyboard-only users can become disorientated as the focus indicator will disappear from view until the user has moved to a focusable element within the viewport.
  • Make links easy to identify. Make links clear and easy to distinguish from emphasized or body text.Make clickable targets bigger. For example, using display: block within a navigation menu to allow users to click the area around the text or making clickable buttons or links larger. In addition to attracting more attention from all users, this particularly helps users who have impaired motor skills.


  • Validate your HTML and CSS. Invalid code isn’t necessarily inaccessible, but may cause the page/site to behave unpredictably, which may in turn cause problems for assistive technology.
  • Check color combinations. Use a tool which tests against the Luminosity algorithm and test for color-blindness issues using an appropriate tool or simulator.
  • Ensure fallbacks are in place. Check that all important functionality works without javascript, CSS and images.
  • Unplug your mouse. Before trying out a screen reader, unplug your mouse and try using the site/theme with keyboard only. If you can use the site comfortably without using your mouse, you’re doing very well.
  • Use an automated testing tool. Tools like WAVE can help you identify coding errors and suggest areas which may require further manual assessment.
  • Get an expert review. If you don’t feel that you have the experience or knowledge to fully test the site, get an expert to review the site.Do some user testing. If at all possible, ask some people with disabilities to test your site/theme and observe them while they’re using it.

9 thoughts on “Designing Accessibility Into Themes”

  1. Great summary, I had actually never thought of screenreaders reading ALLCAPS text differently, it’s probably not well-known because I see plenty of websites that just use ALLCAPS text in their source code.

    All this stuff is great advice, thanks for taking time to share!

  2. Thanks Peach. The ALLCAPS issue is a funny one and not one you’d know unless you know someone who’s encountered it in use, but it can make such a big difference.

    Webchick: It isn’t under any particular license, because I didn’t even think about it (but it’s definitely something I’ll think about in future).

    I’m very happy for it to be part of the handbook and released under the same license.

  3. Ann — absolutely *fantastic* list…

    excellent to have all these vital points all collated together – something properly practical to go on 🙂
    Will refer anyone interested to this page …
    Thank you 🙂

  4. This is a handy list. Usually I try to make my sites as accessible as possible but it’s nice to have a comprehensive checklist. Thanks very much!

  5. Thank you Leisa for this posting on what is a very high risk/high opportunity for ensuring that the next major version of this content management system is inclusive of persons with disabilities. As the trend towards dynamic, rich internet applications continues to unfold, and CMSs like Drupal increasingly becomes part of the ‘plumbing’ of these web sites/applications, it is more crucial than ever to ensure that this accessibility is designed in early and comprehensively.

    Thankfully, well architected IM/IT design and accessible IM/IT design are mutually reinforcing as W3C discovered with the establishment of it’s Web Accessibility Initiative. It turns out that accessible IM/IT not only ensures inclusion of persons with disabilities, but a ‘disability dividend’ also results – increasing the quality and ‘future-proofing’ of mainstream technologies. As to the opposite direction, in my opinion the extremely high quality of Drupal’s architecture gives it a considerable head-start down the accessibility road. This is a key reason why we have selected Drupal as the infrastructure for the new site that we are developing.

    As your well crafted listing may imply, it can sometimes be easy for developers and designers to get lost in the weeds of accessibility’s technical details and/or get mired down into debates without a compass to remind them that these details are ‘hows’ and that the important things relate to the ‘whys’.

    While working on the Government of Canada’s Web Accessibility Testing Service, I would often meet government developers arriving, carrying armfuls of technical documentation and standards, ready with all kinds of questions. After guaranteeing to address each of them at the end of the session, I would then invite them to sit with our testers (one who was blind and using a screen reader, and one who was a high-level quadriplegic using voice recognition technology) as they attempted some tasks that any typical Canadian would, on the site of the developer’s department. It was amusing to watch as, being public servants of good will, they would be very helpful to the tester explaining, for instance, how he could find a particular link, or fill in a specific form – until I would reach over and turn off the monitor. That’s when the real learning would begin – and the standards and documentation would begin to make sense.

    Of course these are 2 unique individuals experiencing 2 specific disabilities, and the reality is that people experience disabilities that range in type, quantities and complexity (Helen Keller was but one example). But they do illustrate the need to design for ‘edge cases’ rather than mainstream… which brings me to your principle #2:

    “Design for the 80% ”

    I will not pretend to know what, exactly, is meant by this principle at this point and therefore will assume, for the purposes of my remaining comments, that it refers to designing for 80% of users of Drupal 7 (whether in the roles of administrators, content suppliers, or surfing visitors). If, as is likely, I am mistaken and the 80% refers to something else, then I apologize in advance and hope that my comments will, nevertheless, be useful or of interest anyways.

    If it does (refer to designing for 80% of users that is), then I believe that this might be a mistake. It’s not that I don’t understand the principle: 20% of your clients bring you 80% of your business; 20% of your inventory bring you 80% of your profit; 20% of your carpet’s area contains 80% of the dirt… 20% of the design effort of Drupal 7 will bring satisfaction to 80% of Drupal users.

    This approach is devastating to persons with disabilities. (At least this approach unmodified: read on).

    It has been – and continues to be – a recipe for marginalization of some of the most vulnerable of the population – a population that, nevertheless constitutes the largest minority group of all… and one that continues to grow with the playout of demographics and other factors. Ironically, a population that contains people for whom the web provides empowerment, a population who tends toward a higher than average rate of web usage – despite its barriers.

    May I suggest an alternative – although more challenging – approach? If there is no getting around it, and this principle MUST be applied (i.e. aiming at 20% for 80%), then I’d like to suggest that design – especially usability design – be AIMED at the 20% OF THE MOST DISABLED of the population.

    (…pause, while disbelief plays itself out…)

    The more you think about this, the more sense it makes. While you’re designing for these ‘edge cases’ the most creative, most innovative, most future-proofed, most human-centered, most standards-based, highest quality architectures rise to the top:

    Web applications, websites, or for that matter, pretty much most systems / services / infrastructures that are usable by people who experience various disabilities are definitely more usable to people who don’t – and often are usable by other technologies. A video captioned for people who are Deaf can, for instance, be searched by software. A website that can be used by a person who is blind is almost, if not totally, usable by someone using a mobile device. A website that can easily be used by a quadriplegic using voice recognition or morse-code or scanning-based sip and puff switch technology is definitely easier to use by everyone else (think, for example, word prediction).

    For any of you who are still skeptical (I admit that this may appear non-intuitive at first to conventional thinking), here are some other examples of where the ‘disability dividend’ contributed wholly or partly to the initial development, or enhanced quality of key mainstream technologies.


    Bill Shackleton


    Dean Kamen developed the iBot wheelchair noting that “…after more than 200 years of manufacturing wheelchairs, they still could not go up a curb…”. The technology he developed for his superior wheelchair went into the development of the Segway.


    When he turned 70, Alexander Graham Bell stated that “recognition for my work with the deaf has always been more pleasing than the recognition of my work with the telephone.” Much of what he learned in this work helped him with his invention.


    The first typewriter proven to have worked was built by Pellegrino Turri for his visually impaired friend, the Countess Carolina Fantoni da Fivizzono. The commercial production of typewriters began in 1873.


    As a person with severe learning disabilities, Herman Hollerith incorporated ideas from Jacquard’s loom and Babbage’s Analytical Engine to create an electromechanical information machine that used punched cards. His Tabulating Machine Company became IBM.


    The first practical use of a transistor was a reliable, powerful, flexible, smaller, cheaper, cooler-running and less power-consuming hearing aid.

    Records & Tape Recorders:

    The 33-1/3 RPM record and the tape recorder were invented and developed to enable the blind to listen to books.

    Music Keyboard

    Inspired by Stevie Wonder – his first customer for his Reading Machine for the Blind – Ray Kurzweil invented the first synth keyboard using acoustic sound

    1. hi Bill – thanks so much for sharing your thoughts and concerns.

      I agree that ‘design for the 80%’ might seem to imply that people with accessibility requirements fall outside of this 80% but that’s not the way we see it at all, hence the importance that we’re placing on accessibility in our design considerations and getting Ann involved early in the design process.

      The way I see it, almost any of us can very quickly develop requirements for ‘accessible’ websites – as easily as a broken arm from a ski accident, developing RSI, leaving our glasses at home or – the thing that is inevitable for all of us – getting older!

      So that places accessibility requirements firmly within the auspices of ‘designing for the 80%’ from our perspective.

  6. Thanks Leisa for your reply. Given the quality of your post and your response to my comment, I have no doubt that you share a understanding of accessibility.
    Perhaps I should clarify my concern, as well as the transformative shift in perspective that I am proposing regarding principle #2.

    My concern is based on almost 25 years of personal experience in this field – of first hand exposure to, and awareness of the insidious creeping and ultimately robust systemic discrimination. Most barriers don’t tend to arise by intention, but DESPITE the best intentions and actions of designers and developers trying to do good. It’s usually not in the large decisions when setting out, but in the myriad of day to day technical flesh-outs and implementation choices made under timeline and resource pressures that seemingly harmless pieces are put into place that ultimately have such devastating consequences to some individuals with disabilities.

    An exception to this general characteristic of small-over-large, adhoc-over-planned capability for making barriers can be illustrated by the above Principle #2 (Paraeto). Accessibility issues will often make it to the ‘In Basket’, however in practical real-world situations, the inbox is never empty (there’s almost always things to do than time and/or resources to do them) and by the time these issues have risen to the top, the moment (timeline) has passed where real substantive strategic and design choices could have been made that positively affect the smaller but multiplicated choices downstream. That is why so much accessibility work is retrofitting and patch-work. Although 1 or 2 people might understand the initial specific, clarified intention of (for example) “Design for the 80%”, the reality is that the overwhelming majority of downstream designers and developers – lacking the context that currently exists – will not share this understanding. Upstream decisions as stated (rather than as intended) create the context for downstream decisions. Unless done at the start – when foundation and fundamentals are put into place – ‘doing’ accessibility is difficult – at least more difficult than, say, visually-oriented design (which, I’m sure you’ll agree, generally predominates in the world of design). Just as Mark Twain said (I think) that the longer I work on a book, the shorter it gets, the longer a downstream visually-oriented designer works on her site, the higher the probability that the accessibility part will get to the top of her to-do tray – the reality however being that she probably won’t have the time to ‘edit’ her site to be usable to that other 20% (the disabled 20%). In her eyes (or those of her boss) that work represents diminishing returns.

    Transformative Shift in Perspective:

    Leisa, despite your much appreciated recognition that ‘disabled persons R us’ (whether us with a broken arm, or us older), when it comes to developing most technologies and systems (web apps and CMSs included) the reality is that without specifically targetted focused and explicit modeling (through personas, use cases, etc.), persons with disabilities ARE peripheral to the focus of development which means that they will not be within the 20% area of focus (to generate the desired 80%).

    The challenge that I am throwing out with the proposal to explicitly move persons with disabilities into this 20% circle of focus (unusual though it may seem) is to identify what would be pushed out, and comparing whatever that is with what it is being replaced by.

    From what little I have learned so far, it appears to me that usability is right up at the top of Drupal 7 development priorities. This implies to me at least the addition, if not direct focus, on ‘human-centricity’. If I am correct in this assumption, then what better way of making Drupal’s administration clearer and more understandable to human administrators than to design it so that a person with a learning disability could quickly get up to speed and use it…. to have effective ‘just-in-time’ reminders so that a person with memory impairments could use it… to have the states of partially completed processes preserved so that an easily tired person with multiple sclerosis could stop, take a rest, and then pick up where she left off after… to ensure that a person who is blind and can’t ‘drag and drop’ can, nevertheless still reorder their widgets using the keyboard or voice recognition and screen reading feedback … so that, for example, everyone else can just use their telephone…?

    Leisa I hope you (and anyone else reading this) see this for how it’s intended – as a conversation meant to inspire a more human-centric approach than what has resulted in the past. If we continue to do the same thing the same way, we’ll continue to get the same result: marginalized persons with disabilities and in many cases, predictable mediocrity – although given the quality of Drupal’s community and software, I highly doubt the latter. In fact, it is this very quality that excites me… trying to imagine the true transformation that could result from the sustained focus of this incredible community of designers and developers towards a truly (disability-related) human-centric bulls-eye.



Comments are closed.