Surmounting Technology's Limitations: A Conversation with the FCC's Jamal Mazrui

Jamal Mazrui, Federal Communications Commission (FCC)

Jamal Mazrui PhotoJamal Mazrui works at the Federal Communications Commission (FCC) as Deputy Director of the Accessibility and Innovation Initiative. The Initiative, launched by the FCC Chairman in 2010, seeks to facilitate collaborative problem solving among industry, consumer, and government stakeholders so that people with disabilities can reap the full benefit of modern communication technologies. Jamal manages a team of staff who pursue non-regulatory approaches to reducing the gap between emerging and accessible technologies, using techniques of open government such as challenge competitions, developer meetups, and shared data about accessible solutions.

Previously, Jamal worked as a legislative analyst at the U.S. National Council on Disability, and as a database administrator at Harvard’s Kennedy School of Government. He graduated with a Bachelor's in operations research from Princeton University in 1986 and with a Master's in public policy from Harvard University in 1988

Jamal Mazrui has both a professional and personal connection to accessible technology. He's the deputy director of the Accessibility and Innovation Initiative (A&I Initiative) at the Federal Communications Commission (FCC), the independent agency of the U.S. government that regulates interstate communications by radio, television, wire, satellite, and cable. Jamal is also blind, and a developer and user of technology inside and outside the workplace. PEAT recently spoke with Mazrui about his work and his own personal experiences with workplace technology.

PEAT: Can you tell us a bit about your role as the A&I Initiative's deputy director?  

Mazrui: I manage a work team that supports a non-regulatory approach to promoting collaborative problem solving efforts on accessibility, all with a goal of ensuring that people with disabilities can receive the full benefits of modern  communications technology. We use open government tools in our initiative and operate what's called the Accessibility Clearinghouse, which is an online information hub on the accessibility features of communications products and services, mostly about mobile phones so far. Most of that data is presented through a syndicated feed through a collaborative understanding we have with the Mobile Manufacturers Forum, an industry association of mobile device manufacturers.  

My team also issues public challenges to stimulate progress. For example, this is the fourth year that we are operating an award and recognition program called the Chairman's Awards for Advancement in Accessibility (Chairman’s AAA). We’ve also held developer conferences to help IT developers learn how to code accessibly for different platforms. The A&I Initiative also hosts a Speakers Series promoting big ideas on how to encourage innovations in accessibility. So it's very exciting work.  I'm happy to say that my position takes advantage of my strong interest in designing the best public policy to achieve whatever the goals are, while respecting the accessibility implications of trends and emerging technologies.

PEAT: Tell us about your career trajectory.  How did you end up working in public policy?

Mazrui: Well, my career has combined my strong interests in public policy and management information systems. They’ve taken on different emphases at different points in my career, and I'm happy to say that my current position at the FCC is a combination of the two.

Technology limitations did pose some barriers in the early days of my career. In the early 1990s, for instance, I worked in software development of database systems. But when the graphical user interface of Windows supplanted the text mode of DOS in the business world, a viable screen reader did not exist. So in order to surmount that barrier, I made a career move to policy analysis rather than software development. I have gotten back to some software design and development again, since screen reader functionality has substantially caught up to market needs. But it still remains challenging to develop in highly visual areas of desktop, web, or mobile apps because the leading developer tools often lack compatibility with assistive technology devices such as screen readers.

PEAT: What technologies do you currently use on the job? Do you use any productivity enhancements to help you do your job better?   

Mazrui: I primarily use the JAWS screen reader (software the FCC has licensed for employees who are blind) on both my home and work desktop computers. I also use some free, open source applications that I personally developed for maximum productivity with a screen reader. These include EdSharp, which is a text and code editor; FileDir, a file and directory manager; and PDF2TXT, a batch converter of PDF files to text. 

Additionally, I use custom JAWS scripts that I developed for increased browser productivity with Internet Explorer. You can find a list of my open source projects online.

With my smart phone, I use the built-in screen reader and the voice dictation app. 

PEAT: Do you ever face accessible technology challenges? How do you work around them?

Mazrui: I find the “track changes” feature on the word processing software we use to be challenging to use with a screen reader, so I usually enlist help from a part-time reading assistant at the office when I need to review or contribute edits to a document that's being drafted. I also find creating slide presentations to be challenging, and the email web app I use when teleworking is usable though inefficient with a screen reader.

We also have regularly required online trainings here at the FCC for issues such as cyber security, and I find some that are accessible and others that are not.  

The reality is that virtual desktop technology is being rolled out in many federal agencies, including the FCC, which allows users to access their desktop applications and files from any computer with an Internet connection. But for now, employees with disabilities will often not have that flexibility because of current incompatibility with many assistive technologies. So I believe strongly that federal agencies need to jointly address the challenge of making virtual desktops as accessible as traditional ones.

PEAT: You mentioned that you use a smart phone. How have you found the accessibility of mobile devices and apps that you use to work? 

Mazrui: My smart phone is not currently configured to work with my office email, but a Bring Your Own Device policy is something that FCC employees with disabilities are working toward with our CIO. I find that, on average, smart phone operating system apps tend to be more accessible than desktop or web apps, partly because mobile user interfaces tend to be more simple and straightforward. Among other things, I use mobile apps for tracking news, setting reminders, texting, and reading books.

I find that, in general, apps on the smart phone tend to be more accessible than web-based or desktop apps. If accessibility was not considered in the design, a smart phone app is more likely to be accessible anyway because it is more focused on doing a few tasks rather than providing a complex set of choices. Also, for my smart phone in particular, developers have to use manufacturer-authorized authoring tools, and although I find it frustrating that those tools are not more accessible to use, the one advantage of using them is that the developers tend to use the built-in widgets or user interface controls that come with the brand’s proprietary operating system. And that, in itself, makes it more accessible than using custom widgets. You’re more likely to get custom design widgets in desktop and web-based apps. 

PEAT: What advice would you have for technology companies looking to integrate accessibility into their development process? 

Mazrui: I'd tell them to apply the relevant set of accessibility guidelines for the platform/operating system in question. Usually, the platform developer publishes accessibility guidelines that result in compatibility with assistive technology. That advice typically encourages the use of built-in user interface widgets of the platform, rather than custom widgets, because the built-in ones are designed to incorporate the accessibility API (application programming interface) of the platform. For example, if it’s a website, they'll take a look at WCAG (Web Content Accessibility Guidelines) and ARIA (Accessible Rich Internet Applications).  And if it’s an iOS or Android, Blackberry, Google or some other smart phone operating system, check for accessibility guidelines for developers on their websites.

When technology companies identify relevant guidelines, they should look for authoring tools that support those guidelines. So if you're developing a software app, you would look for authoring tools that allow you to use the built-in widget user interface as much as possible. If they are web pages, then look for tools that support WCAG.

For example, some tools will automatically prompt you for a summary attribute if you are creating a table, or for an alt tag if you are inserting an image. This prompt allows you to input a description of the contents not visible in ordinary browsers, but available to people who use screen readers.

Often, tools these days will have an automatic testing mode that can be performed as well.  That said, automatic testing is usually not enough, but it’s a good first step. 

In addition, developers should create relationships with users with disabilities who can manually test their products and give feedback. One approach to doing so is to get in touch with major consumer organizations like the American Council of the Blind, National Federation of the Blind, and others, and ask them for help in recruiting people to help test your products. 

Companies should also make sure they have very open communication channels with their customers to report any accessibility problems and to get help.  The easier they make it to hear from the customers, the better feedback they will receive.

PEAT: Do you use social media to perform any job functions?  If so, how have you found the accessibility of the platforms you use?  How has this affected your performance or productivity?

Mazrui: I've used relevant groups on LinkedIn to do outreach for events organized by the A&I Initiative. And occasionally, I've followed certain hashtags on Twitter to keep abreast of a topic. But often, social media websites are challenging to use with a screen reader because of the amount of dynamic features that lack full accessibility support, whether in the HTML code, the web browser, or the screen reader.

PEAT: Do you have any favorite technologies or applications that you use for work?  How do they help you? 

Mazrui: The app I mentioned earlier called the EdSharp Editor helps me edit, sort, and search text in flexible ways. FileDir helps me organize, convert, and search files on disk. And I also like Windows Internet Explorer because it helps me research topics on the web, excerpt text, and download documents.

I often use my smart phone for reading. It gives me the option to choose from existing articles, but when I need to perform searches, it gets more difficult for me. I would take advantage of more apps, if I had a better solution for inputting text efficiently and reliably rather than using the virtual keyboard. Some of my favorite phone apps are NPR News, WashPost, and Audible.  I would love to use voice activation, not only to launch an app, but to control its user interface, which is generally not possible now with my smart phone.

PEAT: How do you stay up to date on technology and accessibility? 

Mazrui: I subscribe to various newsletters and listservs to keep me up-to-date. For example, I subscribe to eFedLink, ePolicyWorks news, AAPD Disability Daily, TopTech Tidbits, W3C’s WAI (Web Accessibility Initiative), Section 508, and the FedAccessibility Yahoo group. I’m also on most of the major blind programming listservs from around the world, such as program-l at freelists.org, the blindwebbers Yahoo group, and the script development lists for the JAWS and Window-Eyes screen readers.  

PEAT: What advice would you give to other technology users with disabilities related to employment?

Mazrui: My advice is to learn to use your assistive technology well, and to maximize built-in accessibility features in your products. Make use of support options, including documentation, training, help desks, and peer-to-peer connections. If you are the type that can do programming, screen reader scripting can really make a difference to the usability of some mainstream apps. 

Be sure to learn your tech-related rights under the Americans with Disabilities Act, Communications and Video Accessibility Act, and Rehabilitation Act. Begin any self-advocacy efforts by assuming that an employer will want to fix an accessibility problem if informed of it. Always document the nature of a problem you experience as best you can, as well as how it can be replicated in order to help in the debugging process. When problems do arise, give the employer/developer the benefit of the doubt in terms of how they will respond, because if you bring a problem to their attention and document it well, they should work with you to resolve the problem. If your repeated attempts don’t work, be willing to pursue administrative procedures to exercise your rights. Become involved in the accessibility community, join relevant listservs, and, if you can, attend accessible technology conferences or events. It’s great to just go through the exhibit hall and learn about the latest innovations. 

PEAT: Why do you feel partnerships like PEAT are so important?

Mazrui: Accessible technology requires synchronization among different components that contribute to the overall user experience. Cooperation is needed from partners behind the different components that need to interoperate. Software programmers, web developers, browser producers, assistive technology manufacturers, rehabilitation professionals, and employers all play key roles in achieving successful accessibility for employees with disabilities.

Categories