A11yNYC Jan 22 2019 - Time Traveler's Guide to Accessibility Mechanics - Léonie Watson
So. Welcome everyone, to. Our, second. Accessibility, New York City. Meet. Up of, 2019. So, our typical schedule, is to have our meet up from the first Tuesday, of every, month we, are very excited to have Leonie Watson, here today from Bristol. United Kingdom, so, we are having our event. On a different schedule that's, why we're having two on this month because we're so excited I've. Had four here this is such a great opportunity so I'm happy to see a lot of people here, always, be aware for our events. We're. Gonna have the, captioning. Available so, up on the screen with, the presentation. We always have carte, communication. Access real-time, translation. Today. We have mirror by night from, Lecter captioning. Providing. The. Captions, for us thank. Fog. So. We always have that at our urban we. Also have jolly McPhee here doing our live stream and so if you're never able to come are unable to come to any of our events we, always livestream the. Event, thanks. Jolly's. Work from and jolly, help me out with the proper way to save the new working group. The. Accessibility, special interest at, the Internet Society and. So we. Always appreciate, being. Able to have this stream any of the talks if you haven't been here before or you've come back we always we have all of the talks from the meetup archived, on our YouTube, channel. My. Name is Thomas Logan I don't think that introduce, myself so I'm one of the organizers here, if you haven't met me I'd love to meet you after. The event we also have all of our other organizers, here today as well we, have Cameron. Sean. And. Tyson. The back and, Tyson. Is also, here works, for thoughtbot who is the space that we're in today, so we always think you'd have thought thought for being our event host we've. Had a lot, of great events here and continue, to be. Appreciative, of bop-bop for. Their sponsorship we. Also have level, access and Adobe. As sponsors, now for our music event and we, think both of those organizations for. Helping make sure that we can always put on an accessible, and inclusive, event. With. That being said I think we're now, ready to hand it over to Leonie and learn about the. Time travellers guide to accessibility, mechanics. Hello. And thank. You very much for turning out twice, in a month I hadn't realized this was the case so it's really very sweet of you all to come, along to this talk my. Name is Leonie until, very recently, I worked for the past yellow group known as TPG. Now I'm proud. And somewhat terrified, to tell you that I'm the owner of a new company, called tetra logical working. In accessibility, but, with a focus on emerging technology. Like the voice, assistant, applications. As, well as some traditional, consultancy. In accessibility. Today. I'd like to talk to you about accessibility. Mechanics, the past the present and the future and why, it's important, for all of us who, particularly. Code, for, the web to, be, time travelers to take the best of the past the present and the future to, make things as accessible. As we possibly can so. For. Browsers for, browsers or engines or organizations. That are responsible, for browser engines, at, least in the case of Microsoft, until.
Not. Very much longer but, these will not be familiar to you they're the applications. That are the popular. Tools certainly, in the western part of the world for, consuming. Content, on, the web. Many. Of you might also be familiar with the, assistive. Technologies, known as screen readers and the ones that run on desktop. Platforms, if, you're not a, screen, reader is now available, on all, common, desktop, platforms, as well as mobile so, on Windows, there's, narrator, that's integrated on Mac, OS there's voiceover, that's integrated, on Linux, you can sometimes, get Walker integrated. If you use the Ubuntu. Distribution, otherwise. It's available as a download, and on. Windows. You also have the open source free NVDA screen reader and the proprietary, jaws screen reader and the, screen readers pieces. Of technology, that convert. What's on screen visually, into. Synthetic, speech or refreshable. Braille so someone like me who's blind and can't see the screen can, understand the content. So. Let's have a look at the past and particularly. At the relationship, between these, two things the browser and the screen reader because, it turns out they actually have a very very, interdependent. Relationship. What. Used to happen back in the 90s when Windows, was the only platform that had a screen reader worth its salt the. Browser, would take an HTML, document and it would pass it and it would display, it visually if you included form fields, or other things you could interact with it, would provide the necessary interaction. And then. The screen reader would come along and do more or less exactly the same thing completely independently. It, were to take the HTML, and it would pass it but. This time instead of displaying it visually it would create something that we now know as the virtual buffer an alternative. Version, of the HTML document specifically. For the screen reader and the screen reader user to be able to interact with, on. The one hand this, was quite useful because it let the browser do what browsers did best a screen, reader do what screen readers did best and in, both cases to. Do what they thought best for their particular audiences. It. Did have some fairly fundamental problems, though when, you ask two people to go away and interpret, the same piece of information almost. Invariably, they will disagree, on how it should be done the other. Problem, was that with this particular relationship. At the time if the. Browser crashed it took your screen reader out with it or vice versa if the screen reader crashed it took your browser out with it and pretty much nothing but a reboot would cause, things to settle back into happy, working mode so. It wasn't a particularly brilliant, way for things to happen but it did do the trick and it, enabled, people who use screen reading technology to. Consume. Web content, in a reasonably, useful way. Heading. Level one using the Aria current attribute, posted, in link Co things On January 14. 2017. It is common on the web for the current thing in a collection to be highlighted, visually but providing an alternative, for screen reader users has often involved, something of a hack that linked Aria current attribute has intended to solve this problem so. In, the 90s what screen readers used to do for the most part was just to read content pretty much top to bottom almost, like today you would read a text document there.
Wasn't Very much in the way of useful navigation, available, to screen reader users, or. Anything. Very much other than an ability to, read text. By. The 2000s, things had started, to change and the. Browser's had implemented, support, for things known as the platform accessibility. API s and, screen. Readers had begun using these api's, to, ask the browser for, accessibility, information so. Instead of going off and doing their own things separately the, browser now passed the HTML, document and produced, the visual display and the, interaction, and it, also made, accessibility, information available, to screen readers when they asked for it. There. Our platform. Accessibility, API is on every platform windows, actually has three, currently, it has UA. A sorry. UI a MSAA, and I accessible, to the. First two are its own the second one is what enables, applications, like Chrome and Firefox to, be accessible, Mac. OS has X API, Linux. Also has its own api's and, these. Exist. Within the operating system to let the screen reader ask for accessibility information about. Pretty much anything that's on screen so. It might see a button, on screen and ask, the API give me all the information you've, got about this object, on the screen and it will get some useful information in return. When. It comes to the browser and the HTML elements that we know all about there's. A lot of that information, for. There for free so. For example if we use something like the main element, the, browser will, expose. A numerator, of, different pieces of information about, it it, will expose its role in this case that it's supposed, to represent the main content, area of the page a screen. Reader will ask the browser when it finds this element hey, what is this thing what's its role what's its purpose the browser will tell the screen reader and the screen reader will say something like this to the user. Main. Region it. Just announced it's quite simply to the user that they hit the region of the page that represents, the main content, something. Very similar happens, with the nav element the, browser says, to the screen reader this element has a roll of navigation, and the screen reader can pick that up and tell the user that's what they're dealing with. Navigation. Region. Something. Like, element. A number of things happen here, the screen reader can find out from the browser that the, o/l itself, is a list but. The browser is a bit smarter it counts up the number of list item elements inside the list and it. Tells the screen reader how, many of them there are so a screen reader user gets, an immediate sense of the fact they're dealing, with a list and that it's got three items in it a. List. Of three items one. Do this to. Do that three. Do something else list. And so. You hit the one two three because it's an ordered list and the screen reader picks that up from the browser and what, you may be missed at the beginning is that it said list of three items so the, screen reader user is immediately, aware of the size and quantity of the list that they're dealing with, headings. Have the same thing they have a roll of heading that the screen reader can pick up from the browser. Heading. Level 1 and, it also picks up the number of the heading through another property that the browser makes available in this case the level of the heading in question, it. Also works with a form element so for example we could take a check box an. Input with a type of check box and an Associated, label element using the for an ID attribute, pairing, the, browser connects, up all this information it, associates, the label with the input and makes. That information, available to the screen reader user uses. The type attribute to, tell the screen reader user that, they're dealing with a check box as opposed to perhaps a radio button or other form of input and of. Course the screen reader can come, along and use, all that information to, help the user. Maybe. Oh. No. What it can do though is to tell, the user that they're dealing with a checkbox and as, the checkbox is checked the.
Browser Will also send a notification to the screen reader to live in the u.k checkbox, not checked, check. That. The checkbox had been checked there we go. And so, all that information just keeps coming from the browser to the screen reader for the asking, lastly, I'll take the favorite, of all accessibility. Talks the button element and this. Unsurprisingly. Has a role of button something. That's a little bit different here is that the text, inside the button elements provides. What's known as the accessible, name for the button this, is how the, screen reader differentiates. One button on the page from any other buttons that might be there. Please. It's. Gonna do this to me all the way through isn't it sorry. We come on now to the presents and things. Have moved, on a bit from the days where, we could build or did build web technologies, websites using only the, elements that were prescribed. In HTML. For. Some time now best, part of a decade or more we've been. Creating. Things that don't exist naturally, in HTML. We've, been inventing. Controls. That we use very routinely in software applications. But, we've been inventing. Them or coming up with creative ways to implement. Them in the browser context. Tabs and tab panels are a notable, example. We've. Been using. Mostly div and span elements, to do this we've, been using them as our building, blocks for, the. Custom UI controls, that we create, but. There is a bit of a problem, div. And span elements don't have any really useful, accessibility, information when the browser sees one it doesn't. Convey, any information. To the screen reader user at all so. If we see something. Intelligent, like, this toolbar, all, the screen reader is aware of is the text inside, of the div, and span elements, it, might be styled, to look like a toolbar might be JavaScript it to behave like one but, as far as the screen reader is concerned all the browser has, given it is just the two pieces of text on the page the rest of it is utterly. Oblivious. To the screen reader. Fortunately. We can do something about that we can use Aria accessible. Rich Internet applications, to, polyfill, the missing accessibility. Information when, we need it aria. 1.1. Is the current, official recommendation. From the w3c. Aria. 1.2, is well. On its way to. Heading. Down the path to become unofficial, standard, and it, gives us a bunch, of different attributes that we can use to add accessibility, information to, things like div and span elements, when we need to fill, it in. The. Roll attribute, has. More than 70 different values in the Aria 1.2, specification. And with. The roll attribute, we can take something like a div or a span use. The roll attribute, and depending on the value we give it we, can fool, the browser into, thinking. That it's a completely different sort of a thing and there, are roles for almost every kind of UI control, you can think of for buttons and radio buttons for, tabs and tab lists for progress browsers and toolbars for tables cells and the, list goes on as I saying pretty much every kind of control and interaction, point that you can think of by. Now there. Is a role in Aria to let you reproduce, that accessibility, information, so, if you're using a div in a span that doesn't have a roll of its own you, can use the roll attribute, with one of these values to make sure it has the right accessibility. Roll information. There. Are also 45. Or more Aria. Prefixed, attributes, and, these can be used to, add different, kinds of accessibility, information or, properties, or characteristics, things. Like aria-pressed, four, buttons re-expanded. Things that expand, or collapse, are. Required. For things that must be filled in in a form Aria invalid, for those that have been filled in within.
Correct Information and so, these two we can use when we're creating custom components, to, fill in the accessibility, information that, otherwise just wouldn't be there, so. We can take I will, say this a truly terrible example, please don't ever do this it does happen in the world though a span, element, pretending, to be a button as. It stands at the moment we take a span element with the word play in the middle to simulate, perhaps. A play button on a video player but. Because there's no accessibility, information in the browser the screen readers got nothing to go on except, for the word play so we have to set about fixing, this particular problem, and we, start with the role attribute, and in this case a value of button if. We add that to our span, the. Browser in, its accessibility, tree, will, now present. This piece of HTML as, though it were a button the. Accessibility, tree is the, structure, that the browser creates, to, hold all the accessibility information about, the elements on a page it's. Completely, separate to the document object model the Dom that we use for interacting, with things like scripting, so. It's only in the accessibility, sense is this thing now pretending. Or being presented, as a button in every, other respect it's still just a plain old span. We. Can add in the tabindex. Attribute because, one of the other things, that a span doesn't do is any form of interaction you can't focus on it with the keyboard if you click on it with the mouse nothing very much happens, either so. We start off by using tabindex, with a value of zero to make sure that someone using a tab key can focus on the, button, which. Is obviously pretty important if you want to be able to interact, with it, we. Then have to provide the interaction. Developers. Often are. Quick to put in the mouse. Interaction. The mouse functionality. But, of course it's important to add in the keyboard functionality, as well the expected behaviors of a button of course are, to be able to press them with the space or Enter key so. The JavaScript that we use to create functionality. For the button has, to listen for both of those things for when someone presses the space key or the enter key and it has to trigger the functionality, when either is detected. So. Now we have another demo which is almost certainly not going to work but if, we do all of this our span should, actually behave, some things like this. Play. Button. So. We, had a play button which, is pretty much what. It says on the tin it's a button we, play as its label and when. Activated. It looks like it's pressed. Except. You may have noticed that the screen reader didn't. Communicate that, piece of information it said there was a button there but, it didn't acknowledge that it was either pressed or unpressed, or anything, of the sort the. Solution in this case comes with one of those Aria prefixed, attributes, the Aria pressed, attribute, and if. We add that to the button, with. A value, of false initially. The. Screen reader will now determine that, it's a slightly different kind of button it's a toggle button I mean one that can be toggled on or off and as. Someone, either hits it with the Enter key space key mouse taps, on it we, toggle that value to aria-pressed equals, true and the. Browser will now let the screen reader know that that button is currently in the pressed state. We. Can then actually tie in the functionality of the button into that attribute, so. We can make. Sure that as someone, interacts with the button the value of the aria-pressed attribute, is changed appropriately. Toggles, on toggles off toggles to true toggles, to false.
Something. Nice you can do if you're building something like this is actually attached that functionality. And the, CSS together, so. If you make the CSS. Change the visual of appearance based, on the, value, that the aria-pressed attribute. Has you. Get quite a neat effect it's, particularly useful if you are wanting, to bug-fix, your code a lot, of accessibility particularly. The accessibility, that we use to help screenreader users in Aria is invisible. If you're, developing unless, you're testing it with a screen reader you, don't notice all of the accessibility things, that are going on with the browser and the screen reader but, if you tie the visual, appearance into. The Aria state, if, you, press your button and it doesn't look like it's been pressed the, first place you need to go looking is your accessibility information, to see if the Aria pressed attribute, is in the state it should be so it's a useful way to hook, things together a little bit more usefully. Into a visual paradigm, as well an accessibility, one. What. We do with this now is we get a slightly different experience, for, the screenreader user I think it's pressed. Play. Toggle button not rest press. Press. So. Now it's announced as a toggle button as I mentioned but, also the current state of the button is communicated. By the browser to the screen reader whether it's pressed or not pressed so now we've got a much more complete experience. Compared. To the visual experience or the mouse users experience. The. One thing I will notes because it's, just the way things are rather. Than doing all that tab indexing, and, so. Java, scripting, around we'd all be much better off if we just use the Aria pressed attribute, on the button element if, we use the button element we get the keyboard focus for free we, only have to provide the JavaScript, for the mouse because the browser will hook it into the keyboard interaction, for you automatically, we don't have to worry about the role equals button either the. Only thing we have to add in is aria pressed to get that state, change information so, fewer, moving parts much. Less prone to breaking, so using the button element is always much better than trying to fake it with a span. We. Also now in the present day are moving into an area where web components, and custom elements are becoming more and more popular, one.
Of The leading energy suppliers British gas in the United Kingdom has just released, a brand new version of its home page that's almost entirely populated, with, web components and custom, elements, so, this is technology, that is now increasingly, hitting production, mainstream. If. You're not familiar with it a custom, element is, an. Element that does. Something that doesn't, exist natively. In HTML. So we can create. Elements. That do things that we, haven't previously been able to do unless, it was by using div and span elements and a whole bunch of bunch, of scripting and Aria to make things work. So. We start off and, we extend, the button element in this case we're going to extend HTML elements, to create something called the T button or a toggle button and we. Can put. That together there's, a point in the code where you attach something known as the shadow root. That, may not be a familiar, term to you but for those of you who are developers, you'll be more familiar with the concept than you might think where, use, something, like the audio or video element, we, just literally put, open. Video elements give it a source close, the video element but, when someone views it in the browser the. Browser has obligingly, populated. The page with all the buttons and sliders and, other controls that you need to, be able to play. Pause, change. The volume change, the incremental. Timer all of those things we, don't have to do that as developers. The browser takes care of it and that's. The basic concept of a shadow root what we put in the HTML. Actually. Has much more going on under the hood that isn't. Immediately, obvious from, the HTML, that we write and making, a custom element is very very similar when. We come to write the HTML code, for our element we'll just put a very simple, one line of HTML in, we'll see in a minute but, there's a lot more going on under the hood that, won't ever be visible to the end-user or even to someone having, a look at the code of the website.
So. We can just see the constructor, there and how, its put together and, where we've got the the shadow root being attached, this, is a very simplified example because. You can't squish too much code on a slide unfortunately, without so getting unreadable. We. Can take the code, from our previous custom. Toggle, button example, so, we can put exactly the same JavaScript riffin, functionality, in to use the aria-pressed, attribute. On our toggle button and, remember all this is happening tucked, away out of sight of all the code of the web page so it's, a much neater, way from a coding point of view to use. HTML, with custom elements than to have to put all this into the HTML page itself or its associated documents. So. So. That's what we would put in our HTML we would just open a toggle dash button elements but the word play in the middle pretty, much the same as we did with the button element with. Custom elements you have to have a hyphen or a dash in the middle of the name somewhere, it's the easy way to distinguish, them from quote. Real HTML. Elements, or not but. From a user's, point of view or ease from a developer's point of view this is all the code we would need to put in our HTML page to produce, toggle. Buttons so all of the Java scripts hidden out of the way as is, most of the rest of the code, what. We happen when a user comes along and uses this with a screen reader is something like this. Plea. Toggle. Okay. It's, not feeling like it so essentially it's very much like the custom, button from before it, gets announced as a toggle button and it states of pressed or not is announced. But, from the, implementation, wrist press. Point. Okay. Let's go right from, the implementation point as a developer, we've got much simpler, code to write and of course we can reuse these custom elements, as many times as we like across the website all you ever had to do is just. Write the toggle button code in your HTML. There. Is a problem though all. Of the code that, we wrote inside, our custom element is hidden out of the way much like it is for an audio or video element, except. For the Aria if you. Go and run, this in. Your browser and you go and then inspect the code you'll, still see the Aria pressed attribute, present on the toggle button even though it, was never actually applied, by you in the HTML, at all and. This is what's known as leaking, HTML. Or attributes. In. This respect it's perhaps not, a major problem but, it does make for kind of untidy, Ness and developers. If nothing else like tidy code we like things that are nice and clean and orderly with everything in its place and everything. Having a place and so, this, leakage. Of accessibility, information when, we write custom elements is, a bit of Aksum from a development point of view and so, we. Move on to the future and work. That is going, on to try and solve the, problem of Aria. Leakage, when, we write custom elements and also, a potential, solution to making it easier. And perhaps more interesting for developers to be able to deal, with the browser more directly in terms of the accessibility, information and, it.
Comes In the form of something known as the accessibility object. Model it's. An experimental, JavaScript. API that's being developed by, people from Apple Google and Mozilla. Github. URL. Is, up, on the screen and I'm sorry I don't recall it to read, it out but. It's being developed very, much in the open and. I want you to bear that in mind as we go on through this because commenting. On standards, like this that are developed at the w3c, is, incredibly. Important, from, all of us who has any occasion, to think they might ever want to use these standards, it's, can't, really be emphasized, enough how, useful it, is for specification. Editors to hear from people who will ultimately be using the standards that they create to make sure they're heading in the right direction not, doing anything crazy, or unhelpful. So. There are lots of phases to what's happening with the aom the first one is that. You'll. Be able to use, Aria. Element. And attribute, reflection. This. Is also being, featured in the Aria 1.2, specification. So it's the thing we're most likely, going to see has some browser support, in, the very near future and. It's quite a simple change but it really simplifies, the, way we can set accessibility. Information using, JavaScript, at. The moment what you have to do is write the kind of quite clumsy code. Something. Like button dots, set, attributes and then give it the the. Name of the attribute and, the value of the attribute as, arguments, it's. Not a big problem it's not too unwieldy but, again developers. Like things neat and tidy and what. This phase of the AOM will let us do is use a more conventional, common. JavaScript mode. Of doing things so you'll be able to do something like button, attribute, name so in this case button dot roll equals, and. Then, sorry button dot roll maybe equals button, there's. Another example up on screen which is, button. As in the thing we want to apply the accessibility, setting to aria-pressed. True. You'll. Notice if you're familiar with Aria. And recall, the, Aria prefix, that I was mentioning earlier that, in the AOM all the dashes, in the Aria, -. Something, attributes, has vanished so Aria - pressed becomes just aria-pressed one, word so, that's a slight oddity in the change. Of the syntax but this, in theory will make it easier to write JavaScript. That. Sets accessibility, settings and, has them recognized by the browser so so far this is looking like a positive thing. Phase one B will. Elect, authors, when, they're particularly, writing, things like custom elements set some accessibility characteristics.
At The time the custom element is created, and, these are immutable they're not going to be changeable, once the elements, is actually being shown up in the browser you, won't be able to do anything to change the values that are set at this time so, this is much like the browser already, provides all that accessibility, information we saw at the start things like the role and other bits and pieces it. Will also be possible though, to change, some other accessibility. Characteristics. In, response to user interactions. So aria-pressed is another good example of this when, you user presses, a button we want to be able to change the aria-pressed, state, and. That's going to become a lot easier if this phase of the AOM goes, ahead. Phase. Two, there. Will be the, opportunity to respond. To new user. Events, things. Like increment. And decrement. Page. Scroll up page scroll down these. Are particularly being, added in not so much for desktop, use but for mobile use. Being. Able to increment something or decrement something is an extremely common pattern on a touchscreen device as, is scrolling, page up page down but. There are no specific events. To deal with this and saying that we've got you know key down events, and mouse. Click events and all sorts of other events now these. Were missing and so it's going to introduce some, new events that we can respond, to in our JavaScript. Phase. 3 is where things really start, to get interesting, and I, say interesting both in quotes and out of quotes interesting. In the sense of quite, exciting it will let us add, virtual. Accessibility. Information to the accessibility, tree in the browser up, until this point the browser is the only thing that, has have been able to get its hands on the accessibility, tree this. For the first time will give us as developers JavaScript. Access to that information and the ability to add, new. Information into, the accessibility tree so. It will be possible to add something into the accessibility tree, otherwise. Doesn't exist, on the page itself, and, this, is where the interesting with quote marks comes in on, the one hand this could be a horror story waiting, to happen we. Could very well end up with, a time where, there, are two, completely. Separate, versions, of a, piece of content one, in the accessibility, sense and one in the what everybody else gets sense. My. Personal thought is that if you've gone to the trouble of learning all your Aria all your accessibility how, will these mechanics, work you're. Probably not, going to be the sort of person that's going to go down the route of developing two completely, different, and independent, implementations. Of the same thing I do. Think it might well have some uses though one. Of the things I really, dislike, but, still find necessary is the need to use. Java. CSS. To hide some information, off-screen usually for, the benefit of screenreader users doesn't, happen so often these days but there are still use cases for doing that the, problem of course is that if you are someone who doesn't use the style sheets provided, by the website I, doesn't. Have the style sheets that hide that text out of everybody else's view you're, going to get all these peculiar, little messages, that mean absolutely, nothing to you because, you're a low, vision person who just prefers, a different set of style sheets so, it always feels a little bit hacky, a little bit dirty with. The AOM if this phase comes, into being we. Could for example use it to provide those little snippets of information that aimed very specifically, at screen reader users without, risking, them getting in the way of anybody else's experience, I think that that, has some merit. Baseball. Is the final phase. Of the AOM and it, will just really tie things up one. Of the most interesting things is it will let through. JavaScript, it'll let us walk the entire accessibility. Tree so, we can do this with the Dom already in fact we do, it to find, out how many elements of X variety, there are on the page and then we we do some interaction, based around that this. Will enable us to do something very similar so, it would be possible to, create, quite screen reader like functionality. As, part of the scripting for a web page so if you wanted to add in some particular functionality. I'll. Use heading navigation, as an existing example, by, walking the accessibility, tree a screen reader is able to tell how many headings there are on the page and provide.
The User with the functionality to jump quickly from one to the next using a shortcut with. This ability to walk the accessibility, tree using JavaScript, developers. Will effectively be able to create, interactions. Shortcuts, bits and pieces like that for themselves and again that. Could go either way it could get really complicated, or, it, could be really useful, and the, truth will be if we get this far it'll probably be a little from column a and a little from column B. Before. I just finish up with some final thoughts on why we need to be a time traveler there is one important thing I want to say about the AOL as YouTube one, is that as it stands at the moment there, isn't any browser, support, for any of this not. Even behind the flag as I said it's very likely we will see browser support, for the first the. Attribute. Reflection. Probably. Within the next few months I should think as for the rest of it it's, still very much a work in progress, and there. Are a lot of questions, that the editors and the community, working, with them need to answer and that's where input from people like yourselves becomes, incredibly important, one. Of the biggest questions, from my point of view is that of privacy, because. There's a very interesting dilemma, coming, our way well, coming my way certainly, and that's, that once. We allow developers. Access to the accessibility, tree it gives. Them the ability to identify that, the person using the website not. Only has a disability but, very specifically, is a screen reader user and that's. Because the, browser doesn't, create the accessibility. Tree unless, it sees an assistive technology running now, that might be any assistive, technology, a screen reader screen magnifier, or speech recognition tool but. The, only accessibility. Syst of technology that really supports. Aria in any fashion is a screen reader and that's, what the accessibility, object model is all about is a different way to use Aria to change the accessibility, tree, so. We, have a big question around, how. Much of our privacy are, we willing to sacrifice in. Order to be given an accessible, experience, I'm. Pretty clear on that I'm not willing, to you, know give, away that much of my private information I quite, happily stand here and talk to you about being a blind person, but my choice to, do that in the time in the place I see fit, I don't. Want every, advertising. Person who, has JavaScript. And accessibility chops, to be able to find out amongst, goodness, knows what else they already seem to know about me that I'm blind and I use a screen reader that really, really makes me unhappy as a prospect the. Editors of the AOM are very well aware of this and they're trying really hard to, find solutions, but it's a difficult problem and this is where input from as many people as possible becomes, incredibly, important, to try and answer these big and really quite difficult questions. But. Back. To the talk and why. It's important to be a time traveler, quite. Simply we have a lot, of good accessibility things, we can call on we, have the native, accessibility. Of HTML. In the original sense we, have the ability to add in accessibility. Now with Aria, in many, different versions and as.
We Move into an area area, where we get to be able to play a little bit more directly, with the accessibility relationship. Between the browser and the website and the screen reader we. Have even more exciting, possibilities. To call on but. If we don't take the best that, we've got from the past and the present and the future if we don't time travel a little bit with our accessibility, then. We're really missing a trick because none, of these solutions in, and off themselves none, of them in their own right enables. Us to make the technologies, that we want to create today as accessible. As we need them to be so. Thank you very much hmm. So. With the design of. Is. The layering being taken into account. That's, a very good question, so, you know the editors do include. People like Alice Boxhall from Google who are very. Well versed in accessibility, so they are thinking about the complexity. Like. A, lot. Of people who are very focused on on trying. To find a solution to a problem, it's. Perhaps true that they don't necessarily consider. All, of the angles well haven't so, far and that's again brings me back to the point as to why it's important to hear from the likes of us who you, have to go and use these things eventually, but. I think, it's the. Layering thing is interesting I think it's almost like a transfer, of power or transfer, of responsibilities. You know back. At the beginning it was screen, really did its thing the browser did its thing now what, we're getting with the the AOM is that we're throwing developer. Into that relationship, as, well so, so you know what we used to have to rely on the browser or the screen reader to do then. The browser and the screen reader now, we. We can kind of inject ourselves into, that that process and. What's, the phrase you know great power comes great responsibility that. Remains. To be seen and as I said I'm, pretty, sure we'll see a lot of good coming out of something like this if we can fix the big questions like privacy but, the complexity, will almost certainly.
Mean. We end up with some pretty disastrous outcomes, as well I expect that's what happen with Aria so. I. Had a question on just. The, custom, element. Concept. Which you know currently exists, in HTML, so if you built, a custom element right. Now the solution. Is you would add, the Aria attributes, on to the sort. Of top-level element, and that is, removing. The tidiness, but, is still something. Possible. Or are there like when you get into. Complex. Custom elements not a way to actually make, them accessible today no, it's more that when you, are writing your custom element when you actually creating, the. Hidden code part of it if you, use Aria, anywhere. In that that shadow. Needs, shadow part of the custom element, it. Will show up in the. Rendered HTML of, the page so. You don't, have to apply the Aria direct to your toggle button as it was in my example, when, you write toggle button into your code just, the fact that the Aria attribute, was used in the, that. The shadow Dom the hidden away part of that element means, for the moment the browser will cough, it up and add it to the HTML toggle button element whether you like it or not and. That's where the messiness gets because you've you've, tried to contain everything else inside your custom element so style sheets are contained, the behaviors, contained, none of that sort of escapes outside, of the element that you're trying to create but the accessibility, at the moment does does. Leak out sideways and that's the bit they're trying to solve right ok and then, there are I mean as far as us, as a community, you. Mentioned, contributing, or having. Comments, on to, the the github. Sort. Of working group that's a place to add comments is there any other things. As far as. Evangelizing. To the Browse manufacturers, are letting them know like. That means. So. The github it or add repo. Is definitely the place to put your comments in that's that's where they're paying attention the. People who are working on the spec as. I said it's members of Apple Mozilla and Google so browser vendors who are writing, this spec because. From their point of view it solves. This custom elements problem quite quite. Neatly and Google particularly, is very highly, invested in, custom. Elements with its polymer, web. Component library so, they really want to to solve this so to, that extent you, know the browser's are pretty well involved already what. What, I don't think we have enough involvement. From is our community, as. I say people who are going to ultimately, be using this one it when it becomes supported. So. Yeah the github github, repo is definitely, the place to ask questions though there are really friendly bunch the editors who work on this and ask. Questions they will try to help great. Thank you get. A question up front. I've. Got a silly question. Some. I had my coat lint it for accessibility. I got hit for having an emoticon, in my code and it said that's not accessible remove it so I was wondering if you have thoughts on emojis. And emoticons inside, of you. Know content that's in a unicode. Emoji, yeah, more or less like happy face or sad face instead of like you know literally like some words in place and and I had. Some linting tools set up that would catch kind of all the low-hanging fruit and that one was like don't use it and I was like oh that one just bummed me out so.
That's An interesting one and actually, the unicode emoji now are reasonably well supported, certainly by screenreader. Different. Screen readers only, the very newest generation, five or six I think, aren't. Terribly, well supported say so now as a rule if you use, one of those emoji in your code anywhere the screen reader at least will recognize. It so I guess what it was being failed on was probably no accessible, name something. Like that if, you want to take, a very, robust. Approach to it the way to do, it is a little, bit tacky. But it does the trick. Wrap. Your emoji in a span give the span a roll of image and then. Use aria-label, to give it an alternate, texts and, that should do the trick. If you come and find me off the truck I loved, about this a little while ago I can point you at an article. Thinking. About that but yep that should do it mm-hmm. All. Right Chuck, we've. Been doing. A lot of development with accessibility. Development, coming across issues. With reCAPTCHA. We're. Wondering the company called a a 360. Who's. Who's, doing, our audits and they're. Like well it's, the, best thing out there but it's. Still not it's it's still not great so especially as a blind user. What's. The frustration, factor with three captions, or anything out there that you've noticed that is kind of better for you as a user but. Still provides a security level needed for. Baman. So. So, Version three of recapture. Which. If you're, not familiar with the generations, actually doesn't require any user interaction at all all. Things being equal. Is. Not too bad as. A first attempt if you trip it, that's. When it gets complicated no, matter what form because, then it will start asking, you to you know recognize pictures. Of things and other bits and pieces and I saw a great tweet a couple of days ago which is am I the only one that finds it worrying that Google are developing, self-driving, cars and they're also the ones asking me to identify traffic, lights by. Geniuses, over the web in less, than 160. Characters so. So yeah recap 2 3 providing. You don't trip it is actually pretty unintrusive, it's. Intrusive in the sense that I still don't trust anything that recognizes. I'm using a keyboard and, possibly. Other bits and pieces but perhaps that's just you know my, sense of privacy going. Back a generation to recapture to which is the one that asks you to check a box to confirm, your you're not a robot I don't. Actually find those too problematic, providing. I know they're there that's usually the biggest catch. For me I tend to find I've submitted a form and only when it doesn't work do I notice there's a little message, that says. Convinced. Me you're not a human. I'm. Not a typical screen reader user so I wouldn't necessarily take, my word for the average experience, it's. With the old school property which is that of course you you run into to trouble generally. Speaking I I don't know about anyone here and the visual ones but I can never solve the audio ones I I can, either understand what they're saying but I can't get to the Edit box fast enough to type them or. I can get to the Edit box fast enough to type them but I can't understand, a word of what's being spoken to me so. It's. Kind of degrees of awful I actually. Still have yet to be convinced that captures, are necessary, at all but sadly. It seems a lot of people still really believe they're the only way to to. Stop, both sigh I, think doing things like you, know checking, for frequency, of form. Submission so if someone's trying to, bash. A an. Account registration or a login until, they they you, know think they've found a genuine. Email address or something like that you know you can you can protect. Against that by checking. For the frequency, that you know the service being pinged. For. A download of the page I think, there are better ways we can solve this problem but, I'm.
Not An expert in that field and, clearly. A lot of people think. Otherwise. Yeah reCAPTCHA 3 is probably your best bet at the moment if captures, absolutely, necessary. Thanks. Thank. You neo. I just want to follow up on the capture because I do work with low. Vision and blind users. Also work, and producing digital talking books and Braille large print etc, and I do have an experience that I would love to share because this just happened last week where, I have a user who tried, to use CAPTCHA, they're a low vision user they tried to scale up on the screen everything up blurred so. They went to the audio, version and. Unfortunately. This view sir speaks, multiple languages, so when you go to the audio version you hear multiple languages, this person could understand all of them except for the language that everybody was expecting which was listen, to the English side of the audio and fill, in the blank with what was, available and timed out every single time because they would hear Arabic in the background they were French in the background and the, users spoke these languages, so, it created, more confusion and. More of a barrier to access. The. Other one that I do remember from a couple of years back was when Google would begin, Auto filling, user. Name and password fields this, user would go to say. Gmail try, to log in the field was already filled but, was never told that the. The username or the password field had already been filled in so. They were trying, to type in their password on top of having their password already filled in and they were being denied access so. I just want to share that experience yep. Good. Examples. So. Um my. Name is Jake I have a question kind of more about so. We're looking at this from the the, approach. Of the markup the HTML that we're producing to, make things successful, I'm kind of curious what screen, readers are doing, to make what's. Being read out loud more, predictable. And. I'll give a very concrete example of something, I work with forms a lot and very frustrating. User experience, I saw was I'll, make up a cup the combination, I think was jaws in Chrome or some combination of a screen reader in a browser and there. Was a required field that was blank and when. You were using, the screen reader and you toggled, into the required field it rambled. Off the label, required. And then said invalid. Which. Is really drawing because it's not invalid, you just haven't proceeded. To engage, and, enter something and, then if you switch over to a different screener it read a totally it didn't have that problem and. I'm. Kind of wondering are, the screen or companies trying to come together on some spec on what should be read. Out loud when, you engage different, elements, similar to how CSS they have really, strict specs when they talk about as. Esoteric, is a bulleted list you know preceded, by a paragraph, how it should handle margins, and they get crazy on those specs and I. Feel like that's the other side of this like how are they what, are they doing to improve the. Standard. Which I feel like there isn't a standard I know. And. Aria. As, a spec which I suspect maybe, to.
Cause What's. Causing that the problem you just described in which have a screen reader it was I see. This is quite a common pattern actually people. Will put Aria invalid. Equals. True on an empty form field before anybody's got as far as filling anything, in and. You're right it is extremely, jarring if, that gets picked up so maybe if you look for that you might solve. The problem, in the short term if you, remove that until it's needed to of, a larger question though the screen readers aren't working, together to find any common Allen see the. One thing I would say though is most. Most. Users don't switch from. One screen reader to another so they don't know about these these, differences, it's. A bit like back in the days, when we had a lot of, browser. Differences, in CSS as you mentioned I remember, working with clients a night but but, the logos five pixels, to the right in IE them, wherever, it is in firefox and people get incredibly. Stressed, by this and. You had to sort of point out yeah but most. IE users, aren't using firefox so most Firefox users aren't using IE and providing it looks okay in both, everybody. Should be happy and it's a bit like that with screen readers it's, very tempting on your tests with a lot of different screen, readers and a lot of different browsers to get very worried by discrepancy, sometimes perhaps, like when you've just described they are more more legitimate. Than than, some of the differences, but but users are generally, oblivious to these things that they're, just used to the experience they get from the one that they use most of the time the. Other problem of course is it's not just the screen reader it's it's so, fundamentally, wrapped up in what information, is available from the browser and that changes from one browser to another as well so. Trying to find some consistency is, pretty. Hard unfortunately.
But. So you I think we really wanted because, that's what I was taking away I was looking at these quirks lack, of a better word and I, was going in the mindset that someone, just, gets used to that quirk the first, time they go to a forum it blurts, out invalid, on an empty field and it's not they, move on. Well eventually. Event. To. Varying degrees you, do. Then a degree of just. Obliviousness to it the same with pronunciation I get. A lot of people how should I write content in a way that's accessible to screen readers write, content in a way that's readable by everybody else and leave us to ignore the peculiarities that, you know our screen readers Chuck, our way and one, thing I will say though if you do notice something certainly for Jaws, has an open issue tracking out on github, if. You come, from-- you afterwards and give, me some way of contacting you i'll drop you a link or you should be able to google, it NVDA, has an open issue, tracker as well so if if there are things sound, like you picked up a jaws chrome bug there it. Might be worth just checking that out and filing an issue there and. Saying. You can get it fixed. Hi. Leonie this is Cameron, the. The. Conversation, about screen readers and its nuances, and quirks and inefficiencies etc. I mean it. Kind. Of dovetails with a lot of developments, and voice, assistance, that we talked about earlier and. Also, with. Being able to augment content. With the accessibility object, model. Do. You see, these, changes. Impacting. The usage, of screen readers as they. Stand, do. Screeners. Feel like a. Satisfactory. Solution, to, the problems, that we're describing and, how, do we do better maybe. In the context of voice assistance, or maybe otherwise. That's. An interesting one I don't think that voice assistance, are going to replace, screen. Readers on mobiles. Or laptops. Or whatever anytime soon for the. Simple reason that. Voice. Interaction. Is very much in the here-and-now you, you ask it a question you, get an answer you. Maybe get given two or three options that you can choose from and you can remember two or three options and you choose one and it and it goes on you know down the conversational. Path. That's. Great for very simple one track, interactions. But a lot of the stuff that we do on the web on our desktops and laptops is, a lot more complex it involves. Being. Aware of maybe two or three pieces of information at, different places on the same web page if. You're searching for a flight for example, you, know you might be filtering based on price or class, of ticket or something, like that trying. To do that. Successfully. At the moment through voice interaction for anyone it is incredibly different but is that the, mode of conversation, isn't actually particularly, well-suited to, to more complicated, tasks, certainly, not at the moment that, might change I'm. Not sure we can do much to change how, conversation, works and how capable humans, are at conversing, though. Conversations. Generally. Are quite quite simple one track things, as. To where the screen readers are the right solution. That's. A good question I often, hear people say you know if we were to do this all again today we probably wouldn't create screen readers but I don't, think I've ever heard anybody, what they would create if they didn't. Whether. That's because it's really hard to think of something in the way cuz screen readers are just so big and so ubiquitous and so much they're you, know it's it's like sometimes when you're staring, at a wall you've painted blue, and trying to think what it would look like if it was red it's it's just really difficult. So. I don't know it is that is the short answer to that I I suspect we could come up with an easier solution screen, readers are difficult, but. Again don't ask me I really couldn't tell you what that might look like, okay. Thank, you. So. I worked at opera on what we would create instead, of screen readers and, that's. A fairly convincing, reason why we don't. The. But, but the general thing of. What. Should, we tell people about when, not. To interfere with, what. Screen readers do and, and. Either. The, same thing I mean again, an example from opera opera had. Navigation. Like. Screen readers now have when, screen readers didn't have it and it was fantastic.
But. Not everyone has that so how do we deal with that, that. Piece, of some. People actually still living in the past, with. Technology. That's not quite up to date. And. How do we deal with the yeah. We have a great way of adding things with the accessibility model. Should. We add them and are, they actually going to help or are they going to get in the way. They, may well get in the way for all the reasons that I, said. In the talk the. Interesting thing about the accessibility model is that actually from, the consumer, point of view from the screen readers point of view it changes nothing, it. Still gets the information from the browser in exactly the way it has done for the past 15 years and, will more or less do exactly the same thing it has always done with it so that, part. Of the relationship won't change at all, so. In terms of catching up from you know what technology you've got what browser you've got or whatever your. Browser is probably the only really important, piece of that puzzle. That. There's a screen reader providing, it set up just to ask the browser for information, well, we'll. Have some success in doing it I mean said there was a very early the AOM that did have some support in browsers and certainly. The screen readers I tested in Mac and Mac, voiceover. NVDA, angels picked, up the new stuff that I'd created without without. Batting an eyelid so, there. Is hope that the legacy technology, thing won't be quite so much of a problem in this case as for the rest of it yeah oh hell could break loose quite, rapidly here so we'll see. Hey. My name is Nikki. The. Past 10 years we've. Been working with this kind, of ideology of mobile first and, not. Only does it affect, the way we think but it also affects, kind. Of our workflow as well do. You envision, am. Being, a new, workflow where it's kind of accessibility, first, and is that something that we can work on first and then work. On these other layers that we talked about the complexity, of these multiple. Layers I. Think. It has to work. In tandem with whichever first, happens. To be flavor of the month at the time. So. You. Can't separate the the. Presentation. Of the content from its accessibility so if you're thinking mobile first and you. Need to create something custom, you've. Got to make sure that's accessible, if the IOM gives you a way to do that you've, got to tie the two together from. The very beginning same, if you take it back step in you know people still doing, kind of desktop whatever.
First. If. I have to put a first actually I'd make it content first and, then. Hook everything else around it but. Yeah. Where. We have a number of whatever's, first choices to make and yeah from a code, point of view mobile first is still incredibly, popular you can't separate it from the accessibility area if, one happens without the other then then you're gonna run into problems. Any. Other questions. All. Right well, I think we just like to say thank you again very much, so Leonie this is awesome, talk thank you very much. If. You have any other questions come and find me afterwards, or my. Contact, info is up on the last screen and. I'll share the slides on Twitter in a moment so please ask, me questions anytime this evening or ahead, and, I'd, like to just, plug her website tink, dot UK there, I've been reading, Leone's. Post you know for many many years and it's always unlike. Some of the latest you. Know technologies, that are coming out there's really interesting thoughts. There much like we had tonight but I would say you know if there's a whole history of, Awesome, articles, on. That site so definitely. Check that out again I want to thank everyone for coming tonight, thank. Our event, sponsors a thoughtbot. The. Internet Society of, New York and the. Accessibility. Special. Interest group meerabai, night from what captioning. Level. Access, and Adobe, we, really appreciate being able to have, this event every. Month and have it accessible as. Always, if you're interested, in communicating, about, another. Event or another, accessibility. Related piece, of information, if you have job. Opportunities, or. Other events, we have Tonya now, in the back here is our volunteer, but we want to start putting those more, out into, the community, and help helping. People that are part of our community learn about other, events that are happening in the city so feel, free to, get, her. Contact, information will be also posting, that on our meetup site. With. That being said you know also if you're looking for presentations. You, know also reach out to us we're always looking to get scheduled. Ahead we, won't have be having an event in February due. To having to in January but our next event will be in March and Cameron, Scott. We. Have a new email address it's, hello at a11y. NYC, hello, a 11y, NYC, so if you need to reach us you. Can email that email address and it'll go out to the organizers, and you'll. Be able to act. On that. Dot-com. Illinois. NYC, Jack. Yeah. And, and for the job postings, for. Events. For ideas. For questions you can you can message us there and we'll be able to get back to. You.
2019-02-07 23:35
