# Accessibility RAAAAWWW

## Qué es accesibilidad?

## Por qué es importante?

No puedes utilizar solo las herramientas automáticas (no es suficiente). S´ˆ, puedes conseguir estandars y llegar a un nivel de cumplimiento de las guías pero realmente, ¿cómo puedes hacer que la experiencia sea sensible, exitosa y tenga significado? Así como conseguir estandars de usabilidad es dificil, también lo es llegar a estándares de accesibilidad. La buena noticia es que cuando mejoras la accesibilidad de un producto digital, inevitablemente mejoras la usabilidad y la experiencia.

Hay tres tipos de razones para mejorar la accesibilidad de una aplicación: razones morales, legales y de negocio.

En cuanto a las razones legales,

El tema de la accesibilidad es que cada vez más nos acercamos a que sea un derecho humano fundamental a nivel internacional. Tanto así, que en la actualidad en los Estados Unidos está requerido como una ley federal. De 2015 a 2017, más de 250 negocios diferentes recibieron demandas en los Estados Unidos. Y hay algunos casos famosos: AOL fue demandado hace algunos años, Target y hasta Netflix ha recibido demandas.

En Europa existe e Acto de Accesibilidad Europeo, destinado a teléfonos inteligentes, tablets, ordenadores y otros dispositivos.

Todo esto ha hecho que las compañías se motiven a mejorar la accesibilidad de sus productos digitales. Y a pesar de que realmente la motivación no sea la empatía, el marco legal ofrece suficiente motivación para que exista una profunda necesidad en las compañías que diseñan aplicaciones a mejorar la accesibilidad.

Por otro lado, están las razones morales. El acceso universal es parte de todo lo que hacemos en el mundo digital. La inclusión de personas diversas forma parte de la tendencia en el diseño web porque, además, es una buena oportunidad para ejercer la responsabilidad social corporativa.

Por otra parte, las personas con discapacidad suelen enfrentar mucha discriminación en cuanto al empleo. Toda esta problemática hace fundamental que enfoquemos los temas de accesibilidad como algo prioritario dentro de nuestro proceso de diseño.

Por último, las razones de negocio son las más evidentes. En la medida en la que nuestros productos sean más inclusivos, tendremos más usuarios potenciales.

## Tipos de discapacidad

Hay cuatro grandes tipos de discapacidad:
1) Discapacidades visuales
2) Discapacidades motoras
3) Discapacidades auditivas
4) Discapacidades cognitivas

El 80% de los problemas de accesibilidad que encontramos en un producto digital están asociados directamente a algún tipo de discapacidad visual.

Ahora, la discapacidad visual va mucho más de la ceguera. En realidad es un espectro. Hay 22 tipos de ceguera, sin embargo, tendemos a agruparlas.

Se puede ser legalmente ciego y sin embargo tener algo de visión. Por otro lado, un usuario que tenga baja visión puede requerir solo un aumento del tamaño de la pantalla para acceder a una aplicación. Sin embargo, magnificar la pantalla ayuda poco.

En Europa, la visión se puede ver comprometida en un porcentaje: sesenta, setenta, noventa... la mayoría de estos usuarios tienen acceso a un lector de pantalla (Screen reader). Estas herramientas leen en voz alta el contenido que se presenta en una UI.

Los usuarios con discapacidad visual tienden a usar estas herramientas, así como también, el teclado de sus dispositivos. Y enfocarnos en ellos también nos ayuda, por ejemplo, a resolver problemas para personas con discapacidades motoras, quienes también suelen utilizar teclados, por ejemplo.

En el caso de los problemas de audición, la incidencia para nuestra industria es menor. Sin embargo, la solución que se ha planteado en los últimos años suele ser suficiente: subtitular los elementos que presenten algún tipo de audio.

En el caso de las discapacidades cognitivas, es un poco más complejo. En este caso, dependemos fuertemente de los tests de usuario. La razón de la complejidad es que entre uno y otro caso hay mucha diferencia. Las discapacidades cognitivas engloban dislexia, déficit de atención, trastornos en el espectro del autismo (como Asperger).

## 10 principios de accessibilidad

...¿Qué le entregaste? Ahora, para el tema de los "alt text", lo que quieres es describi, no la imagen, si no la información que se encuentra dentro de la imagen. Entonces. ¿Que está haciendo la persona de la imagen? como por ejemplo, que viste un traje, o su edad o el tipo de pared que está mirando. No es relevante el color de la pared, ¿sabes? "Hombre mirando una pared" podría ser poco descriptiva; pero dependerá del uso que se le de a la imagen.

Si la imagen es requerida por el usuario para entender el contenido de la página, entonces deberías hacerlo un poco más descriptiva: "Hombre mirando una pared con gráficos e infografías" podría cubrir las necesidades de información de la imagen. Si es muy corta, rollo "Hombre mirando la pared", eso podría ser un poco... ya tu sabes... Si le agregas algo tipo "Imagen de un hombre mirando una pared" la descripción está siendo poco relevante. No necesitas decir "Imagen de" o "fotografía de". El Alt text Es un problema clásico de accesibilidad ya que mucha gente lo olvida o lo pasa por alto. Y eso que este texto es importantísimo para SEO por lo que es muy relevante que sea considerado.

Miremos ahora el tercer punto que es típico en los dispositivos móviles: El menú hamburguesa. Esas tres líneas que se ubican en el borde superior izquierdo de las pantallas. La manera fácil de arreglarlo es simplemente tageándolo correctamente.

**no se entiende esta parte**

Let's look at the third one that's so classic on mobile is the hamburger menu; the hamburger menu, you know, being the three lines in the top left of the screen. The easy fix is to just properly tag it; so, typically those menus

00:06:00 --> 00:06:30
the user, the screen reader just skips over them; users don't see them. They can't actually access them. So, the classic one for mobile there is tagging those mobile elements when they become responsive.

Y el cuarto tema son que los contenidos que se posicionan fuera de la vista podrían no ser encontrados en la pantalla. ¿Qué significa fuera de la vista? bueno, piénsalo así - El lector de pantalla está leyendo esta pantalla: Esto es un mapa, entonces quieres encontrar la dirección de un restaurant pero el lector no ve el listado de locaciones (el contenido que importa)
El mapa no es importante: Eso es un paradigma visual, no? El usuario ciego no verá el mapa, Este mapa de google no será accesible. Es como si buscaras algo entre un millon de imágenes no descriptivas. Entonces, aqui lo importante es el listado de locaciones que hay en esta área para que puedas saber "Oh! si, hay un restaurant cerca mio" Y este listado está ubicado después del mapa y debería estar ubicado antes en el código para que cuando el lector de pantalla lea el código lo lea primero. A esto nos referimos cuando hablamos de contenido "Out-of-the-way": Contenido difícil de encontrar.

El 5to principio es que testear la accesibilidad con usuarios (testeo de verdad) puede mostrarnos un gap enorme, y de eso hablaremos más adelantee donde dedicaremos toda una sesión a test de accesibilidad. Esto es una gran revelación para la accesibilidad, por cierto, debido a que mucha gente cree que pueden apañarselas con _checkers_ o revisión de código. Yo mismo pensaba que podría hacerlo de esa manera. Y déjame decirte que después de 17 años de experiencia en este rubro con mi compañía "Experience dynamics" hemos llegado a la conclusión de que TIENES que testear la accesibilidad. Tienes que testearlo con usuarios reales. ¿No tendría que ser una sorpresa, cierto? ya que... ¿Tu testeas con usuarios... cierto? No se trata de intentarlo, o adivinarlo o de seguir una guía. Pasa lo mismo con los tests de accesibilidad, o incluso más importante. Porque accesibilidad es dos veces más riesgosa que la usabilidad.
A la izquierda ves un test de usabilidad, y a la derecha un test de accesibilidad con usuarios no videntes intentando lograr la misma tarea.
Veamos la tarea 3 aqui.

00:08:36 --> 00:09:02
the right you see an accessibility test with blind users completing the same task. So, you see task 3 here, and it's like three times as – almost three times as easy for users who are sighted than users who are blind to complete this task. And this was chatting with a librarian; so, it's

00:09:02 --> 00:09:33
an online librarian chat. It's like a form dialog box, and there could be a form element as well. I think there was actually a text box where you type your response to the user, and then there's the chat dialog. And it just wasn't tagged; so, a lot of accessibility comes down to improper, like silly tagging, you know – same with task five. I mean, but you can see

00:09:33 --> 00:10:03
the gaps between the two. Now, in this particular test, our client was looking for a usability test, and we said, "You know, you should probably test with users with disabilities because, you know, you're offering public information; this is a public library." They said, "Oh yeah, that's a really good idea." And the other thing that we realized was that when we went to test,

00:10:03 --> 00:10:30
we did the testing in the library, and they said, "Yeah, we have the screen reader; it's JAWS" – it's one of the common screen readers. JAWS is a PC-based screen reader, and then voiceover is on the iOS devices. So, we went to start testing, and they only had a trial version installed. So, their IT department was, you know, taken aback, and they really

00:10:30 --> 00:11:01
realized, "Wow – we have some major gaps inside of the service offering of our software we're offering our patrons in the library" as well as, you know, the website was improperly tagged. The users were not able to even get to this feature; it had a very low success rate. Now, the sixth principle is that disabling zoom on mobile makes it inaccessible, so low-vision users

00:11:01 --> 00:11:34
using screen magnifiers won't be able to actually do the zooming if you disable it. So, a lot of people will disable that on mobile, and it locks users out. So, this is an image of a 400-times magnification by a user with low vision, and that's literally how the screen is being digested. So, the seventh principle is that accessibility is easily learned.

00:11:34 --> 00:12:04
Remember that close to twenty percent of the US population and ten percent of men are color blind, by the way. So, color blindness is another form of a barrier, right? We were sitting at Goldman Sachs for a study we were doing, and this guy – I said to him—we were looking at a screen—and I said, "Well, how about that error right there in the screen?

00:12:04 --> 00:12:35
Does that make sense to you?" and he said, "What error?" And it was a red piece of text, like a little red box around it. And he said, "I don't see any red." I said, "The red box, right there," and he said, "I don't see a red box. I'm color blind." And it was a reminder to me that like "Oh, wow! Yes" You know, even if someone is not identifying themselves to have a disability, there are still, you know, that

00:12:35 --> 00:13:05
the access issue is always there, right? It's always there, just like with color contrast. That's the biggest one. Like, gray on gray seems to be the big one that designers can handle a lot of gray on gray, and most other people cannot, including myself, so. And I wear contact lenses and glasses; so, you know, that's a form of access. So, clean coding can be learned with a

00:13:05 --> 00:13:34
little practice. You know, accessibility is actually cheaper if you do it up front compared to if you try and do it later. So, it should be part of your coding, but also it should be part of your UX design strategy, too. I'll talk more about that a little bit later on in the training when it comes to inclusive design strategies. So, the next principle is accessibility doesn't mean ugly.

00:13:34 --> 00:14:02
It may require you to rethink kind of the layout – again, this is where UX design can be very helpful. But one of the things I've realized is that visual bias is your worst enemy, you know, because you're so familiar with seeing things, and the layout of a screen, you know – the more creative you are, the more of a designer you are; the more creative designer/visual designer, the more biased you're going to be because you can handle, just like you can

00:14:02 --> 00:14:33
handle gray-on-gray and you know clean UIs that people that need very high contrast, very definite articulation of UI elements are requiring, and for you, it's fine if they're not there. This is an interesting one – this is actually again from one of our accessibility tests, and the search UI here called "Results" was leading a lot of users to think that that was

00:14:33 --> 00:15:02
where you get, you know, because it says "Results 25"; so, it's almost like do you need that there? It actually turned out that the data that this search result was bringing back did not even have 25 or more, like there was not—it was maybe six or seven on average. So, it wasn't even required, but it was kind of throwing off semantically – nothing inaccessible, but semantically throwing users off where they're

00:15:02 --> 00:15:34
thinking, "Oh, this is the number of results here." So, the semantics of button labeling and of image alt text is actually really important for sensibility, you know, as well as SEO, and the recommendation here is remove the number of results, and on the left, add the text "Perkins nearest to you," so that it kind of, as this screen reader

00:15:34 --> 00:16:01
was talking through, it could actually provide some context to the content that the user was accessing with their screen reader. So, the ninth one here is to check mobile accessibility; we've talked about a few mobile accessibility issues here separately, including responsive issues. This is the same use accessibility test,

00:16:01 --> 00:16:30
where the link is underneath the map. For some reason, the responsive view pushes the search UI to a link underneath the map into a collapse, and then you're supposed to click on that link and open it up. Now, it's even hard to see for sighted users. Even when I was observing it, I barely noticed this link. What was happening with our blind users was it was skipping right past it, so

00:16:30 --> 00:17:03
it was reading the screen, you know, so it was like, you know, search results, a map edit, search some then blah-blah-blah, and then it was continuing on, and it was kind of like – it was just the fact that it said "edit search"; here, you're seeing the user was turning down her speaking rate in case—because she thought, she went over it like five times and didn't... didn't catch it. It actually was there. I thought it wasn't there. I thought it wasn't being picked up, but it was there; when she turned down her speaking rate, you could hear it being said, but it was sort of mashed

00:17:03 --> 00:17:30
in, and the question was – this was like definitely a usability question, and a responsive design decision is "Why would you need to collapse it? Why not just have the UI, you know, above the map would be better, right?" So, you have it where it was before – even below, if it was there: the actual just UI as opposed to collapsing it and making it a link that said "edit search"; you know, it's

00:17:30 --> 00:18:02
just so that you can see here really where usability and UX play into accessibility, you know. When you're thinking about it, it actually requires you, in the same way that SEO, responsive web design, accessibility requires you to be thinking about things the way a screen reader, the way a user accessing this website with a screen reader would think about it, and it's really tricky to think that way. I need to tell you this. It's super tricky to

00:18:02 --> 00:18:31
think that way because you're not used to it. You're used to your visual bias. So, you're like, "Oh, I can see the link; oh, what's the problem?" And so, this is where accessibility testing can help you get to that last mile of insight. So, the tenth principle here is embrace the access attitude. You've heard already, I'm sure, from some of the things that I've shared with you – the access

00:18:31 --> 00:19:03
attitude. It's people first: design for differences, you know. Clear purpose – so, well-defined goals, and that means understanding your audience; so, we'll be talking about personas later on in this course. Solid structure – so, building to standards. You know, there are great standards; accessibility is based on good clean coding. So, you know, just like alt text – every image needs an alt tag, every single image. That's just part of clean coding, and

00:19:03 --> 00:19:34
it'll make things accessible, and Googlebot will be happy as well. So, easy interactions – everything works across devices; interoperability baked right in; helpful wayfinding – so, you know, it's navigation – clear navigation. You'll see throughout this course, we'll be talking about navigation as well, but one of the things with accessibility is a lot of sites and web apps make it hard for users

00:19:34 --> 00:20:04
to navigate. So, just like we saw with that comparison of the usability test versus the accessibility test, it's like twice as hard, three times as hard to navigate a site if you're using a screen reader, for example. So, clean presentation – supporting meaning; that's a huge one – supporting meaning. Plain language – plain language is really important especially for the cognitive disabilities, such as dyslexia or ADD or ADHD; and then, finally,

00:20:04 --> 00:20:32
accessible media – so, supporting all the senses; so, offering captioning for deaf and hard-of-hearing users; offering alternative formats – for example, if the media or the image is too complex or the table is too complex, you'll need to offer a different way for users to get to it. A classic example of that is an infographic. We're going to talk about how to make infographics accessible a

00:20:32 --> 00:20:35
little bit later on in this course.

So, part of the business case that we made was that accessibility impacts usability and SEO, right? That's huge. Don Norman has a great quote about that accessability is about making it easier for everyone. I like to say that accessibility is the cousin of usability: they're

00:00:30 --> 00:01:01
sisters, and it's because you're optimizing your code, simplifying your layouts, you know – maybe a little strategically for screen readers; knowing that things like maps are going to get in the way or that a layout is going to impact the way that a screen reader accesses it, and it's the same for – if you've done any SEO or played around with the way Googlebot thinks and parses a page, it's very structured; it's very strategic, and once you realize how it does that, you can think that way when you're designing as well – so,

00:01:01 --> 00:01:34
plain English; consideration for the end user; browser and device compatibility; you know, this is where usability and accessibility are combined with that goal of useful, usable, searchable, you know, and the key is quick and efficiently and painless – really, that's critical: like I said, for accessibility, even more than usability. So, accessibility impacts SEO, and the reason is because the better the experience and time on site is the main

00:01:34 --> 00:02:01
factor for – the Nielsen Net ratings, maybe ten years ago, set the standard from, you know, number of unique visits to time on site, which is why Facebook and other sites try to keep you locked in to view their content, because their advertisers incentivize them with time on site. Well, the more you do that, the more Google's algorithm likes your site. Making graphical information

00:02:01 --> 00:02:32
searchable – all graphical information: Google likes that, so that's a ranking indicator. Screen reader testing can also help you figure out what's missing from your SEO keywords. So, if you look at your Alt text, you can be, like, "Oh, wait a minute; we haven't optimized this." Now, the thing I should say is that if you optimize your usability, it doesn't necessarily impact accessability, and if you optimize SEO, it doesn't

00:02:32 --> 00:03:04
necessarily impact accessibility. So, it's really the other way around: modify, optimize accessibility can improve SEO, can improve usability, right. It's not mutually exclusive. It's not mutually bi-directional – so, look to optimize areas of SEO and accessibility overlap. What are those? So, video transcription, for example, image captioning, Alt attributes, title tags, headers (H1, H2), link anchor

00:03:04 --> 00:03:34
text, on-site sitemaps, table of contents or breadcrumbs, content ordering, size and color contrast of text, semantic HTML. So, this is an example from SEO Moz that, you know – it's like if you went to this page and you're trying to, you know, submit your taxes for tax season, which of these would – which of these – if you didn't see the page, calculate your tax return or online

00:03:34 --> 00:04:05
tax return, tax return estimate, tax return refund / rebate, you know; it's that the screen reader's literally reading all that out, so you're starting to think about, hopefully, the experience – the optimization opportunity as audible, you know, something you hear. So, what does it sound like? What does it sound like? Does it have meaningful descriptive text that's just not going to be a bunch of garbage? A lot of people when they're listening to screen readers,

00:04:05 --> 00:04:32
they get overwhelmed – it's totally overwhelming. It's because it's like "blah-blah-blah-blah-blah": most blind users listen to their voices in a much, much faster pace like that. So, it's like, you know: two, three times as fast – like, it's going like this, and it's like all this information. But the reason why it's overwhelming for, you know, someone who's not familiar with it is because – it's all the garbage that's in

00:04:32 --> 00:05:05
there, all the tags and all that – all this just raw web architecture is revealed through voice, and it's totally nonsensical, and the reality is that screen-reader users have to listen to all that, so they have to listen to, you know, 60 to 80% junk to find the one or two things that're meaningful and valuable to them. Right, so you can help by the way that you order your titles, the way that

00:05:05 --> 00:05:24
you, you know, define your headers, define your title tags, your your Alt tags, your image captions, and so forth and so on.

00:00:32
Now, much of accessibility comes down to how you optimize your code. Remember we said that accessibility essentially amounts to building on usability and adding those functional elements – those door handles, if you will, for users as they access UI elements, content, and images and so forth on your screen, and a

00:00:32 --> 00:01:01
lot of that is just in your tagging and your coding. So, it's all about optimization, and in this lesson we're going to be looking at all the different elements of a web page, web application and go through those. So, the first thing I want to say is that there are some basics here with accessibility that we do today, and it's essentially HTML5. So, HTML5 has just allowed much

00:01:01 --> 00:01:35
more flexibility for you to do accessibility, and the other thing that pairs into that is ARIA; so, ARIA is the accessible rich Internet application language that Google put together a number of years ago, and it's kind of become a standard as a markup. It's an enhancement to the semantics of a page, right? So, you're going to be using ARIA and you're going to be using HTML5 in combination. It's important to get your ARIA correct, and so I recommend this

00:01:35 --> 00:02:02
ARIA tutorial and an example here of using HTML5 elements and ARIA landmarks in the same element. So, we'll talk more about landmarks and roles as they exist. Those are kind of some of the central pieces that ARIA built into a page to help surface, you know, to make visible – essentially controls and let users navigate easily through them. Now, if we look at

00:02:02 --> 00:02:36
HTML5 compared to ARIA; so, we have things like a header in HTML5, and in ARIA it's a banner – it becomes a role, right, so you have these roles that are defined, so nav becomes navigation, main becomes main – it's the same thing; footer is the role of content info, and the aside is a complementary and so forth and so on. So, the thing about native HTML attributes is that they are going to be your go-to;

00:02:36 --> 00:03:05
so, use HTML whenever possible. One of the things that we're seeing with ARIA is that ARIA can be misused; it can be used incorrectly, and a poor ARIA-tagged site is going to be more of a nightmare for users with disabilities than one without ARIA. So, you know, there's some people that say, "Stay away from ARIA;

00:03:05 --> 00:03:33
stick to HTML." just because it's more straightforward and HTML5 is fine on its own. Now, there are companies like Google, that, you know, obviously they're biased, so they're all about ARIA – ARIA everything, and I think that you can strike a balance, but if you're developing, you should understand the ins and outs in ARIA and ARIA specifically to accessibility. It's just really a

00:03:33 --> 00:03:41
markup, but it can be used recklessly, and that's where it becomes kind of dangerous.

d
Estimated time to complete: 24 mins
Play
Hide
video transcript
00:00:00 --> 00:00:31
To build on your accessibility smarts with images – we've just been through images and Alt – Alt and contrast, right; it's all about Alt and contrast with images. Well, the next accessibility big piece is keyboard; so, keyboard accessibility – totally crucial, totally critical. So, let's dive into

00:00:31 --> 00:01:01
keyboard. Now, one of the first things that I like to do on a website is just start tabbing through, right, so tabbing through and then arrowing up, arrowing down, left, right, and the ability then to hit the enter key and the shift key. These are my basic – so, as soon as I want to check a website out for keyboard, I tab through: that's the basic. So, for example, I've just been

00:01:01 --> 00:01:38
playing around with Apple's website, to see how accessible it is, since they're committed to accessibility. And there's a lot of tabbing, but it starts to go dead on the arrow keys on a lot of sites, like Apple's site. Not all their pages – again, consistency being the key issue if you want to do this really well. Why wouldn't you want to do it really well? So, the other one is the enter key and finally the spacebar. These are both – these two here – are both for

00:01:38 --> 00:02:05
selecting an object; so, if I click a link, it should be selectable either way, and then this is for going back and up and down through content or forward and back. The issue here with keyboard is logical ordering. Now, of course, since we're talking about optimizing our code,

00:02:05 --> 00:02:34
it's going to be about tagging – so proper heading structure, providing Aria landmarks or Html5 – main nav, you know, the Html5 tagging. And one of the things that a lot of people do to kill their keyboard accessibility is set their outline to zero. And so, that's not going to help. The second thing – and this is actually one of the most important things that you need to

00:02:34 --> 00:03:02
learn from the perspective of building this in up front – we're going to actually spend some time in the next two lessons, lesson four and five, talking about this as well. So, this is really important. It's about focus and focusability. So, focus states, because where you land – where you land on a page, you know, you have a page here and where you go next, you know, it's

00:03:02 --> 00:03:33
almost like a blue outline that occurs, then that is going to determine the focus. So, it's critical for you to plan your focus states. Watch out for conflicts with assistive technology. So, some of the known conflicts that you need to watch out for, so caps lock, insert, plus any other combo – scroll lock in any combo, and then with Mac, specifically control and

00:03:33 --> 00:04:02
option. Don't use – don't assign those keys. Try and stick to standards. When you're assigning keyboard shortcuts, try and stick to standards. It's a little bit like gestures with mobile operating systems. The amount of gestures that you could design for in iOS is very different to what you would design for because most users only use like four or five types of gestures, you know, so specifically pinch and zoom, tap, swipe. That's about it, but there's a ton of

00:04:02 --> 00:04:34
other gestures that you could add in iOS that most people just don't learn and don't know are there, and it's only a very dedicated Apple fan that will learn those and use those and probably the designers themselves. So, the standards, though, are really these – the tabbing, arrowing, enter and space. Enter and space are often neglected. Most people just hit tabbing, and then they

00:04:34 --> 00:05:03
don't allow keying, and then they don't allow the very crucial – this is a target selection: enter or space, and either of those work the same. So, I'm going to share with you some keyboard mapping and testing, and then you can use this kind of little cheat sheet to test the keyboard accessibility. Now, with keyboard accessibility, these are the basics, I think, that you need to just sort of like start doing as part of your behavior, just like you're checking Alt

00:05:03 --> 00:05:30
images. But there, you have to make sure you make it accessible for all of the keyboard shortcuts. So, when you're coming to QA and to testing and that kind of thing, you need to make sure that you've got the escape key in there, right – the escape key being that critical "Get me out of here" key, and then other shortcuts like escape and close. Now, JAWS

00:05:30 --> 00:06:00
has its own kind of menu, so the JAWS screen reader for Windows has its own menu that will come up. Not everybody uses it proficiently – it's different on different versions of JAWS. There are a few related issues there, but basically, there are some shortcuts with JAWS that activate that menu, that kind of cheat sheet, that let you look at the header system, look at the navigation – kind of give you this kind of like summarized meta

00:06:00 --> 00:06:32
semantic tool to get through the content. So, you can use this mapping here to go through. And like I said, in a casual sense, just go ahead and get these kind of down. And, essentially, it's "How do I get through the content?" That's number one. Number two, though, is "What's my focus?" Right? So, what is the focus in terms of when you're designing this –

00:06:32 --> 00:07:01
thinking about going through and skipping through that site, just like the example that I shared with you in the last section there with the new site. You know, there were those two images on there, and when I looked in using the screen reader myself, I was getting hung up on all the navigation and the social icons and all the junk – all the garbage, all

00:07:01 --> 00:07:31
this stuff over here that wasn't accessible: no Alt images on the advertising. And when I had our blind user go through, it was a lot easier and the Alts made sense even though they were redundant, they were doubled, you know, there was caption and the Alt. But that's easy on a new site – if you're dealing with a web application or another type of site or with mobile, you want your focusability to be task-oriented. That's why it's a UX

00:07:31 --> 00:07:49
design issue that you want to think about up front and in advance. So, we'll get a little bit more practice with it when we talk about focus specifically, but this is kind of your heads-up for keyboard and focus being a critical "think ahead"-type issue.

So, we've been talking about keyboard in the essential way – to check that by going through yourself and tabbing, hitting those arrow keys, enter keys, being able to navigate without the bias of the mouse, and that means that you need to design without the bias of the mouse. So, let's talk a little bit about focus control and layout considerations here since we've already been discussing

00:00:34 --> 00:01:03
focus. What is focus, really? Focus is about sensible structure, and that's called "focusability" – when you provide sensible structural cues and ways for users to navigate a page layout – that's focus, and it's a choice

00:01:03 --> 00:01:30
that you need to make from a UX design perspective really up front. It used to be the case that that would be part of something a developer would define as they were trying to optimize the usability and accessibility of a site or page, but it's in the proactive sense, and these days the focus that we want to take is to build this and bake that in up front and define that from a

00:01:30 --> 00:02:04
UX design standpoint; so, earlier on as a UX designer, right. Now, focus, as we said earlier, is about where that – you know, it's kind of like that, where the tab ordering is on the page; so, this is a decision that you need to make, essentially, and it's also a consideration that you decide where stuff is going to be accessed from. So, you remember the grouping that we

00:02:04 --> 00:02:30
talked about with images? So, if I have an icon here and I have some text here, the grouping that we saw – that's to aid focus so that we're not, you know, tab, tab, tab, tab, tab, tab, tab, tab, tab, tab, tab, tab, tab, tab, tab – so, just like reducing the tab overhead, reducing the energy load that's being expended by the user. And, you know,

00:02:30 --> 00:03:00
the goal there is to remove the fatigue really, right, and increase the understanding that essentially a user is spatially mapping the site through either the keyboard – kind of feeling their way through these tab areas of the page or through the screen or through an audible environment – kind of like feeling their way through the information as it's structured and delivered or presented to them audibly, right, through a screen reader. So, if it's

00:03:00 --> 00:03:34
a non-interactive element, you don't need to add focusability; so, this is just critical for interactive controls, you know – things that people can use and need – so, things like buttons, critical links, critical form fields require that focus. It's especially important on mobile, right, that you're like, "Yep, here we go." You've got a form element; you need to fill it in, or a call to action. For example, if you have a call to action, there's a bunch of text and, you know, say, a terms of service kind of thing, where you have to hit agree and

00:03:34 --> 00:04:05
then hit next – you want to add your focus to that button, where the call to action is. So, CTAs – call to actions, interactive controls, that's where we add focus. So, keyboard focus is the location where keyboard actions will be interpreted by the application or by the assistive technology. Now, reading focus

00:04:05 --> 00:04:33
is where a screen reader begins to render the content. So, keyboard focus is the literal – you know, like if I tab through, it's going to land on that, and reading focus is where we want the screen reader to land. So, things like skip links that skip to content; so, if I have a whole bunch of content here and at the top of this page if I had skipped to content, it might

00:04:33 --> 00:05:04
drop me down there, and then this might be a very, very long read; so, I might offer a way to tab down to get down here more quickly. And I think some of these policies – like in that case, they require you to read them, so that may be an accessibility hack that you add in there for reading focus so that users can get down to the interactive elements on the page and that they

00:05:04 --> 00:05:34
can be distinguished, you know, visually from non-actionable elements. So, this is the same for a sighted user, knowing that their cursor can begin in there. And usually how that's done is through adding the keyboard tabbing ability that we talked about in the keyboard section here. So, focus assignment or where you focus the assignment is about directing or

00:05:34 --> 00:06:02
retaining or preventing focus, right. It's usually about, "Hey, here's your task; here's what I need you to do really quickly," and kind of get through. So, it's it's an aid; it's a way to help a user, just like if you were to provide a link versus a button, you know, for a sighted user – the button is going to be easier to see, especially if it's on mobile, you know, if it's a bigger button on mobile

00:06:02 --> 00:06:34
when it gets responsive, it's going to be easier to see. So, focus – directing focus is all about that same goal, of supporting the user's task. Now, the other thing that you're trying to avoid with directing focus is that a lot of screen readers will kind of get behind here, especially like with a pop-up or if you have a hamburger menu over here, you know, with a bunch of links here. Sometimes a screen reader will read what's underneath there – see this all the time with pop-ups, that a pop-up window's

00:06:34 --> 00:07:02
there, and there's some text underneath, and the screen reader is just reading underneath; it's underneath that overlay. And so, if you assign a focus, right, then you're going to avoid that, because it's going to say, "Don't look under there. Look here; don't look behind this menu. Look here on this first navigation item." So, that might be – my focus might be for the first navigation

00:07:02 --> 00:07:31
item and also for the form element on this pop-up, right. Retaining focus now – focus rings can be unpredictable, so sometimes developers assign "outline" to "none" – right? So, they're basically like, "Don't outline that, because the focus ring is a little unpredictable." And that's bad because then you're not providing sensible structure; the user or the screen

00:07:31 --> 00:08:00
reader is not knowing where it's going. So, instead what you want to try is like focus ring, which is a new CSS selector, and that differentiates mouse and keyboard focus, so you could try that instead to prevent that unpredictability with focus ring. Now, preventing focus is the case where we do like a control, you know, a deliberate – what we call a "forcing function" where you're basically saying, "I don't want you accessing this," and that's where you can

00:08:00 --> 00:08:31
use an inert attribute, so the user can't get in there and can't access the focus. So, you know, the summary of a focus assignment is be deliberate about it; choose where you want it to be; design it from a UX perspective up front; think about it; think about the consideration of what you can bring to the users, you know, to the users' tasks in terms of supporting sensible structure or focusability so that they can have a better user

00:08:31 --> 00:09:03
experience. Now, one thing to mention that's involved here with this whole discussion of focusability is headings. Headings are hugely important in accessibility to support sensible structuring – that ability to to get through a design and know where the headers are – so, h1, h2 clarity, h3. There was a period where I was looking at web applications and still the case I

00:09:03 --> 00:09:31
think today with web apps – getting a little better, but historically web application usability left out the headers. It's almost like – OK, you've logged in; you're looking at your account; you're looking at this table, and you know – you don't need to know what page this is. Sometimes there isn't navigation inside a web app, so it kind of made sense to me why that was happening. But what we were noticing is that users were so busy looking at the content, the table, their account settings and then bouncing from this table to

00:09:31 --> 00:10:05
that table and that table to this table and this table to this task and then back to that table. The typical things you would do with, for example, managing your retirement portfolio or your portfolio of financial services or your bank account online, you know – or a number of other types of things you could do with a web application. And it was like, "What page am I looking at?" So, just a lack of structure of h1, h2 is the problem there. It's important not to just try and do this through text but to use the proper semantics of h1, h2, h3, and if you

00:10:05 --> 00:10:32
want to highlight or emphasize an element, use strong or bold and "em" instead of "i" for italics. So, the jury is out on strong versus bold. I think bold is – strong was believed to support SEO, and that was the bias with strong, but it's – Matt Cutts at Google, the kind of SEO voice there, has said that it doesn't

00:10:32 --> 00:11:03
really matter anymore – so either strong or bold will work, but there was a time when it was being recommended; so, if you're using strong tags, that's fine, but bold are also fine, too. So, be careful to use HTML lists properly since they convey hierarchy as well. And so, you know, when you're providing a list, you want to use the correct tags, so "ul" for an unordered list, "ol" for an ordered list with progression, like,

00:11:03 --> 00:11:27
you know, one, two, three, and a "dl" tag for definition list – for structuring definitions within definition descriptions, for example, but your most common one is going to be the "ul" on an unordered list, I think, where you're you're – you know – for example, providing radio buttons for choosing an option, just like you're doing in the quizzes on this course here.