One of the wildest myths I've heard about people with disabilities is that "they can't use the internet."  As if we've somehow managed to get toasters to tell us the weather to solve whatever problem that was, but when it comes to navigating a website without the use of sight, it's all shrugs.  Obviously none of that is true. People with various disabilities use the web every day, just in a way that's different than people without disabilities would.

Okay, there was some sass in my first few sentences, but during my second internship as a developer I was asked to remediate a litany of accessibility issues on a banking website, and it was then that I was informed that people with disabilities who use my websites don't just "figure it out".  They utilize assistive technologies that depend on me building software properly so that in turn it can convey the necessary information to users. Assistive technology (AT) is any device or piece of equipment that can be used to help improve one's capabilities: wheelchairs, canes, screen readers, and much more, but in this post we're only going to focus on the ones that help with navigating software.

Since there are a broad range of disabilities, it stands to reason that different users have different ways of using websites.  So let's talk about some of them:

This is probably the most common type of disability people think of when it comes to web accessibility.  Blindness refers to a significant and uncorrectable loss of vision. Since they usually can't see the elements on a web page, people with this type of disability often rely on screen readers like 

 to read aloud the information displayed on screens. Users who use a screen reader often use a keyboard to sequentially navigate through the elements on a page.  When a document is properly structured, more advanced users are able to quickly navigate by headers, sections, images, links, etc.  Since screen readers rely on textual information, it's important that any meaningful images and icons also have a programmatic text alternative.

People with low vision do have some sight, but that sight may be restricted, blurry, or dim. Some choose to be aided by the use of screen readers, but most often users with low vision still rely on their sight.  To assist with this users may simply zoom up to 200% of the default web page size, or there's magnification software that allows user to zoom in on the part of their screen where the mouse pointer is.  Users are also able to customize and enlarge the text size from their OS settings to adjust the display on websites and app.  People with low vision also rely on inclusive designs to ensure that text and elements have enough contrast against their backgrounds.

Color-blindness often isn't considered a disability by some, but when information is conveyed using only color as the means, a barrier is created that prevents people with color-blindess from accessing.  Often people with this type of disability do not use or have any corrective means and rely on inclusive design to obtain the information they need (e.g. a line graph differentiated by colors could also use different line strokes or differently-shaped point markers).

Deafness refers to the complete loss of hearing, and users with this type of disability often rely on sight to experience the world.  Barriers largely comes into play in regards to media with audio.  People without hearing rely on captions, transcripts, and even sign language to convey the spoken word.  While some screen readers also have speech to text capabilities, most of the time users rely on proper captioning when it comes to time-based media.

Deaf-blindness is a good example of how users can have multiple or compounding disabilities.  Those without sight or hearing rely on braille devices to convert the text on a website to braille that they can feel.  Braille devices work in a similar manner to screen readers, where as long as there is text that the technology can consume, there is information that the device can produce for the user.  When it comes to multiple disabilities, usually making your website accessible for each individual disability will also help those with multiple disabilities.  One exception here for those with deaf-blindness is that they can only consume time-based media via transcripts, and not captions.

Motor disabilities is a broad term to group different kinds of impairments such as loss of limbs, mobility and muscular limitations, and even just sensations of pain when moving. There are a variety of assistive technologies available to help users navigate websites such as specialized mice and keyboards to accommodate limb differences, mouth-sticks, eye-gaze systems, voice-command systems, sip-and-puff devices, switches, and so on.  The most famous example of some with a motor disability would be Stephen Hawking, who used a cheek-device that would move the element focus across the screen, and when it was focused on the desired element, he would trigger an action based on the slightest movement of the muscle under his eye. (Or instead of trying to interpret my bad explanation, you can watch a 

video of Hawking using the device (Opens in new window)

.)  Devices like specialized mice, voice-command, and eye-gaze systems depend on being able to use a website with solely the use of mouse pointers.  The other mentioned devices depend on websites being navigable using solely a keyboard.

Speech disabilities can include difficulty producing speech that is recognizable by some voice recognition software, either in terms of loudness or clarity. Someone with a speech disability needs to be able to use an alternate input mode such as text entered via a keyboard.

This is probably the broadest group, ranging from learning disabilities to memory impairments to seizure disorders.  There's no one assistive technology this group uses to navigate websites, but there are a range of element and functionalities that a website can utilize to help make websites accessible to a wide variety of users.

Honestly this was me trying to keep it short when talking about users with disabilities and the web.  There's much more to consider like the technical difficulties and barriers they encounter on the daily, how to ensure that your website can accommodate a variety of assistive technologies, the differences between technological barriers and best practices, and a lot more. But those are for another post and hopefully this provides a good start to your accessibility journey. Thanks!

Get to know the ways people with different disabilities experience the web and the tools they use to navigate it.

Understanding How People with Disabilities Use the Web

Understanding How People with Disabilities Use The Web

You probably aren’t thinking about them when you go online. (Well, unless you’re playing Wordle.) But words are everywhere. Labels, instructions, buttons, confirmation messages—they’re all crafted to ease you along.

At their best, these words make using an app or website feel effortless. At their worst, they can cause confusion or frustration. These words are 

: messaging that guides users through a digital experience.

The most tangible output of UX writing is that content. But the discipline encompasses more than the words that earn their place on the screen. UX writers create a consistent user experience through content. 

Some of us may go by content designer or product copywriter. We also share skills with content strategists and other UX specialists. It’s an evolving practice, and exact titles aside, one thing unites all UX content folks. 

At EF Go Ahead Tours, UX works in cross-functional squads with product, engineering, and analytics. Operating in this structure means we can think about strategy, content, design, and functionality from the beginning. We each contribute unique perspectives. It's fascinating to get to learn more about what our teammates actually DO in our respective roles. The most rewarding part of this structure is that it’s given me the space to be an advocate for content in tech.

More and more people are recognizing how important content is in the product design process. And it’s pretty awesome to work with ones who do! The inclusion of UX writers will only be the norm when content-focused roles are more widely understood. So let’s take a look at the short version of what UX writers bring to the table.

You want a UX writer in your discovery process. We bring a healthy curiosity to it. I’m talking questions—lots of questions—as we explore the problem space together as a team. Some big ones that drive us might be: 

Is this really the problem we’re trying to solve? Why? What’s the context? What user research can we do to validate this problem? 

We’re here to help teammates articulate questions, create artifacts from research, and keep the larger content strategy in mind during this phase. Plus, we love a good problem statement—and are always up for helping to refine one.

At Go Ahead, our travelers are at the heart of everything we do. Advocating for these travelers, our users, is central to our work as a UX team. So as a UX writer, I find moments to highlight the voices of our users whenever possible. 

This doesn’t always look the same, depending on the problem we’re solving and who I’m working with. Sometimes I do qualitative research to complement the quantitative side of things. Sometimes I’m more involved after it’s complete, shaping the findings into a story. It helps to have a UX team like ours, where we each can wear different hats. 

For example, if UX is doing user interviews, I may be the one doing some or all of these tasks:

Quotes are a simple, powerful way to bring our users into the conversation. I love looking for ways to incorporate them into whatever step comes next, whether it’s an empathy mapping exercise, revisiting the problem statement, or moving on to prototyping. It’s all about keeping our users' needs top of mind as we move down the path to a solution.

The solutions we create aren’t used in a vacuum. Each one is part of a much larger journey someone is on with our product. A UX writer is there to connect the dots and ensure content is presented in a way that provides a holistic experience to our end user.

When iterating on an existing feature or designing something new, we think about the whole content ecosystem. That means considering:

Let’s say we’re building a new account feature to prep travelers before going on tour. Reviewing the journey reminds us that clear log-in flow content is essential for getting travelers to actually use it. Or maybe we’re changing up the way we display traveler info. Understanding how that content has been collected across touchpoints allows us to come up with a solution that really works.

Now, we’re at the writing part! This part deserves its own post so stay tuned. For now, a quick recap of what we aim for.

 Those are the principles I keep in mind when writing the copy that guides a user through a digital experience. Everything I write should help someone complete a task with ease. At Go Ahead, tasks could be anything from making a payment to adding a tour review to 

connecting with another traveler on our mobile app

The copy has to feel connected to the language used on our other brand touchpoints, online and offline. Together, these types of copy form a cohesive narrative for our users. A UX writer doesn’t just create the words on the screen, we shape the larger story of our product.

No pressure, right? Well, we don’t do it alone. We work hand-in-hand with designers to bring the copy and visuals together. Our team uses Figma, a tool that allows me to write directly in wireframes or UI designs and makes this collaboration seamless. 

As the only UX writer at Go Ahead, I can’t be everywhere all the time. Having incredible teammates who “get it” and involve me at the right moments gives me the chance to make a real impact through content. (Thanks, UX!)

UX writing is an emerging, evolving discipline, and it brings real value to the work tech teams do. In short, UX writers:

Have thoughts about UX content or want to connect? 

Photo by Lauren Mancke on Unsplash

UX writers create a consistent user experience through content and play a key role in the product design process. Find out more about working with a UX writer.

Why every product design team needs a UX writer

Hello! My name is Amanda and I am a UX designer here at EF Go Ahead. I’ve been in my role for about 3 years now and I can definitely say UX is where I am meant to be. But, it took me a while to get here. I’m going to share my path to UX to show it’s ok if you aren’t in your perfect role right now–sometimes the journey is necessary. So grab your favorite donut and come along.

I went to school for graphic design (go Northeastern!) and at the time I don’t really remember the concept of User Experience being taught. I learned the fundamentals of color and design and was sent on my way. At the time I really wanted to work in publishing, specifically doing production work at a magazine. So to get my foot in the door, when I graduated and started at a publishing company in Boston that did educational publishing (textbooks). I started as the Creative Associate, which really that meant I was everyone assistant and just did whatever people asked me. I processed invoices and fixed the copier too many times, but I was sitting in on the design team meetings each week. There, the team was talking about how the designers didn’t have enough time to both concept new work, and do all the edits that came back on stakeholder routing. Because I had a design background I asked my manager if it’d help if I took on some of the production work from the designers–they could do all the initial concept work and I could do all the edits that came back on routes. She agreed and let me start assisting the designers. Eventually the designers became to rely on me and I became a full-time production associate, taking all the projects to completion and getting them to the printers, and soon taking on larger design projects of my own.

About a year and half into working at the publisher we merged with another large publishing company. It all happened very quickly. Because essentially we now had 2 people in every role, there were redundancies, and the design department felt the best way to deal with it was doing the inevitable layoffs early on and quick. One day we all came in and were each called into our directors office one-by-one to learn if we still had a job. People either came out and sat back at their desk, or packed up their stuff. It was a terrible day to experience. When I got called in I learned that I was going to be moving over to the project management team and was now a project coordinator - oh and also all the other project managers were being laid off. So, while grateful I still had a job, I realized I was moving into a new role, that I wasn’t super familiar with, and there was no one to tell me what to do. The next day I had to come back and keep hundreds of projects moving forward. I followed what I had seen previous project managers do, but also eventually saw where I could improve on things. I read books, blogs, whatever I could get my hands on about project management. I also learned that my company would pay a significant amount of degrees that related to your job. So, I jumped on that and got my masters in Project Management (go Northeastern, again!). What initially was a role forced on me, became something I loved doing. I really enjoyed being at the center of projects and needing to know all the roles that impacted a project.

I was at the publishing company for about 7 years before I felt the itch to try somewhere new. Over those seven years I had proven myself to be someone that could be put in any role and figure it out–for better or worse. I had continued in project management, eventually being a Senior Project Manager managing a team with coordinators in offices all over the country. I then moved over into a Production manager role, that worked on both print and digital production. For a short stint I oversaw the digital asset management and archiving teams. Towards the end I was leading the webinar & email team, which had such great people on it that I was almost not needed. I then saw an opportunity at Go Ahead Tours for a project manager role. It sounded great - it would bring me back to project management which I liked, but also was in the travel space, which lets face it, is a lot more interesting then the textbooks I was working on. I had also done my co-op at EF back in college, so I already knew the atmosphere of the company, which is important when going somewhere new. I applied, interviewed, and a week later had the job!

I came to Go Ahead in 2014 as the Senior Project Manager on the marketing team. I was a team of 1, but over the next few years it would grow to a team of 3 awesome project managers. It focused mostly all on print and after a few years I started to think about what a next step could be–I loved project management but I was learning the marketing space wasn’t where I saw myself staying. There was a UX designer on the team, but I didn’t manage any of her work and I wasn’t super involved with what was going on our digital space. But, the company soon started really focusing on technology. The engineering team was about 6 developers and a project manager at the time handling all the work for all areas of the business (the website, user accounts, internal software, and more). They were starting to evolve into a lane structure to have teams focused on specific areas and were hiring Product Owners for each lane. One of my teammates, Jessica in marketing, let me know about the roles and that she thought I’d be a great fit. She also told the VP of Technology the same (thanks Jess!). So, even though I hadn’t actually worked in the technology space at all, I had my interview and showed how everything that I had done prior- project management, working with stakeholders, figuring out timelines, etc- could all naturally translate to the digital side. And somehow I convinced him because I became the first Product Owner at Go Ahead!

This put me back in a familiar spot. Being the first, and only, product owner meant I was my own guide, without a manager telling me what I should be doing each day. I needed to teach myself everything that was expected me. I was sent to become a Certified Product Owner at the ScrumAlliance, which was a good course to get a baseline of what would be expected of me. But after that it was all about me and my team of developers figuring out how to work together and build cool stuff. It was definitely on-the-job learning. I made my fair share of mistakes-but that was how I learned what I needed to do to help build successful features in the future.

I was a product owner for about 2 and half years and really loved it. I was focusing on the user account platform which I really enjoyed, as with every release we could tangibly see if user’s experiences were improving or not and get real-time feedback from our sales and service phone staff. I was working with designers from our creative team who did all the UX for the account, and it was through working with them that I realized–hey the UX side of technology looks pretty interesting.

It was also during this time that the VP of Product, who was hired about a year after me, left the company. Instead of filling his space I was promoted up to Director to lead the product team, which was both exciting and daunting at the same time. Also, through another turn of reorganization I started to manage the designers who worked on digital products. This allowed me to really focus on everything that goes into UX work and learn what makes a UX team successful or not. Because the designers were mainly working on UI, I started to focus a lot on user experience work–the discovery, research, user flows, wireframes, etc that all needed to be done before UI could be worked on. It was an interesting dynamic balancing product work, where you try to get stakeholders to focus on opportunities and outcomes, with UX work where you focus on actual solutions. I found myself trying to hold back in Product meetings from talking about solutions too quickly, even though I had a sketchbook of ideas in front of me.

At a certain point balancing the workload of the two sides of the role became a lot and I looked at which part was the most fulfilling. I thought about if I would rather go into work and have a product-focused day or a UX-focused day. After really looking at what the journey would be if I went down each career path I decided UX was where I wanted to focus.

Because I didn’t have a whole UX portfolio I knew it’d be difficult getting a job at another company. Plus, I still had that sketchbook of ideas that I wanted to see come to life and years of knowledge about Go Ahead’s issues and opportunities that I wanted to solve. I set up a meeting with the new creative director, who at the time was back to managing the UX designers again, and let him know that I thought I could be much more impactful as a UX designer. I showed the UX work I was doing behind the scenes, and asked if he felt there could be a place for me on the UX team (which actually wasn’t even a true UX team at the time). Deciding to move into UX actually wasn’t an easy decision. Technically, going from Director of Product to UX Designer was moving ‘down’ the ladder. Some people didn’t really understand why I’d do that. But for me the title doesn’t really mean anything, its the work I would get to do each day. Plus, moving to UX meant I’d still be working every day with the Product team–I’d just get to focus a little less on roadmap meetings and stakeholder management and more on the solving the puzzle of the right solution, which is much more fun in my opinion.

Luckily, the creative director was excited about the idea and thought i’d be a good addition to the team (yay!)-but it wasn’t a quick transition. We were in the middle of a giant revamp of our website so I stayed in my product role to help manage that to release. It took about a year from deciding I wanted to move into UX to officially starting a role as a user experience designer, and it’s been a crazy ride since then. UX now sits on the engineering team and the whole team–engineers, ux, and product- have all grown and are creating new and more innovative features –all while working at a travel company during a global pandemic (more on that in another post).

So that’s my path to UX - it was a long and winding road but every role and experience has only made me a better UX designer. I’m also thankful to work for a company that is open to letting people move and grow their career in different directions. If you have questions or want advice about moving into UX roles, feel free to connect with me on 

In Japan overlooking Mt. Fuji on my yearly work trip

Hello! My name is Amanda and I am going to share my path to UX to show it’s ok if you aren’t in your perfect role right now–sometimes the journey is necessary.

ux.

Understanding How People with Disabilities Use the Web

Why every product design team needs a UX writer

How I got here: Amanda, UX designer