All right, we're going to do a panel now. I knew Monica mentioned earlier we're asking somebody to tweet questions at a hashtag Ask Polymer Summit. So please do that if you have questions. We've also got microphones set up there and there. I'm going to invite my panelists on stage. Please welcome Justin, a software engineer on the Polymer team. Got Wendy, a product manager on the Polymer team. Taylor, a product manager on the Polymer team. Monica, software engineer on the Polymer team. Steve Ormel, software engineer on the product team. And Matt McGnollty, director of Chrome. Please give them a hand. Oh man, there's some good Twitter questions in here. And remember, if you have questions, please just come up and line up at the microphone or something like that. We will start with a Twitter question, though. This is from a few of these that are all related, which is basically Alex just gave a good talk on the importance of HTML imports. And a lot of folks are wondering, it seems like there's disagreement across different browsers about implementing HTML imports. And we also have this question of HTML imports or ES6 modules, like where are these things going? So yeah, could you all maybe address perhaps these two issues, like where are imports headed? And also, how do we reconcile that with modules? What's the dive in on that? Yes, I can start. I mentioned this a little bit off the top yesterday. But yeah, like Rob said, all the web component specs are well along their way, already being implemented in browsers, except HTML imports is still kind of on the fence. It's on hold, is what many of the other browsers are saying. It is implemented in Chrome, but it's on hold on many of the other browsers. And really, that's just because we're waiting for the ES6 modules to land in browsers and to be implemented. And it's actually kind of a funny story the way this happened. As ES6 modules are landed, all the browsers figured, OK, you know, these specs are pretty far along. They'll be here any minute. And then we can kind of wait on how we decide to actually implement HTML imports to maybe take advantage of the same loader that ES6 modules use. So we'll wait for ES6 modules to land. Turns out, like these specs tend to sometimes do, take a little bit longer to actually settle into place with ES6 modules. And so as the ES6 module discussion was happening, at least in conversations that we've been having across browser vendors, there's been more attention focused now back on HTML imports, particularly as a performance primitive. Because with ES6 modules, you're blocking on JavaScript. With HTML imports, you get to take advantage, like Alex was saying, of all these great built-in platform browser optimizations to do background parsing of HTML, to queue up all the requests in an efficient way. And so actually, we've been seeing that HTML imports could be a performance primitive. One thing we're really optimistic about is as ES6 modules are starting to come together, there is a great opportunity to really marry HTML import mechanism, at least loading HTML with HTML that idea with ES6 modules, potentially even something along the lines of an HTML module that would interoperate perfectly with ES6 modules. So we've seen some experiments in this space, and we're really excited about it. So roughly, I think it's fair to say that everyone is generally on board with the idea of the need for a primitive to load HTML with HTML. The question is just how does it interface with ES6 modules, and we've got some pretty good ideas around that. Cool. All right. It looks like we have an audience question. Now, really quick, for all audience questions, I'm going to ask one favor of you, which is to please be considerate of the people who might want to ask a question also. So please know, like, I have a multi-part question, part 1A of seven-style questions. Having said that, OK, sir. Yes, you there. My name's Dylan. I work for Best Buy Canada. We're currently considering Polymer. We were wondering if you had any advice for transitioning your large applications in the past into modular components. I'm just going to repeat the question really quick. So do you all have any advice for transitioning your large existing application over to using something like Polymer? I'll take that one. We've seen customers do this before, where they have, inside Google, we have, I don't know, at least a dozen different frameworks that people use. And when they start using Polymer, sometimes they work from the leaves up. And they'll say, oh, I want to use the awesome material design components, because they need to be material design compliant. And they keep working up from the leaves, using buttons and inputs and stuff. And then they're like, oh, then I have this thing that uses a button and input. Now, I'm going to get Polymer. And eventually, they just don't stop. And they go all the way to the top. So I think when you get interop between whatever framework you have and web components, that's a good way to go. I think the bottom up and not stopping idea also kind of applies to a lot of the products that we've been shipping recently as the Polymer team. So particularly things like the Polymer app toolbox and the shop demo. We've got a few exciting demos that are similar to the shop app on their way. And the idea is it's a really great place to start, the Polymer CLI can download it as a template. It builds right out of the box. You've got a progressive web app in one command, which is great for prototyping and for having something up quickly within a day, within two days, three days to show an executive and really convince them that this is a great experience we can actually achieve. And similarly, we're seeing some people start there and then just kind of continue with that template until it becomes the full application. So similar idea, starting with what we've got as a starter template and then expanding from there.  So I encourage you also to kind of start in a prototype phase maybe with a new bottom-up app and then see how far you can get. All right, this is a fun question. I would like to make the panel squirm a little bit. When will Polymer 2.0 be released as production ready? I can take that one. So first off, we had this plan. It was well thought out for the last 12 minutes to bring the 360 view VR camera thing on stage. And we're going to give it its own spot and we're going to call it Blinky and we're going to throw all the hard questions to it. Last minute it didn't work out, so we came up here. I think the plan is roughly around January to have that come out with the elements and everything. It will come out when it's ready. But we had a stretch goal to try and get it done for the summit. That was sort of known tongue-in-cheek. I didn't want to tell Steve until kind of late, until they really started getting stressed out. But yeah, the idea would be the next couple of months. The holidays add at least another month to that. So that's the plan. One more thing to add is that we are in preview mode now. And I think we were in Polymer One, we got to a phase of Polymer One's development, where it became hard to change things because of the need to not break people. And based on your feedback on the preview, we're sort of in a nice period where we're still trying to maintain backward compatibility with Polymer One. But we have a little bit more wiggle room now. So I encourage you to please play with Polymer Two and give us feedback because it'll help us make it the best we can. So if Steve was like a little bit more devious, you would have realized that he could say something right now on camera about when it comes out that's much less ambitious. Hey, girl, 2017. Exactly. How may I have a computer near you? Absolutely as soon as possible. You could be a manager. OK, so I've got another question. This is one we get a lot. I would say this is like 60% of all questions are this question. What about using Polymer with Insert Framework here, OK? React, Angular, whatever. What about using Polymer with other frameworks? Rob, do you want to take that one? I'm good. I think we have to throw that one to Blinky. Oh, wait. Yes? I mean, I listened to Taylor's keynote yesterday. And what he told me was you don't have to throw out your framework. That's right. Because Polymer is based on standards, it will work with your framework. That's right. And yeah, maybe he can add more. Yes. So yeah, we do get this question a lot of the time. This is one of the big promises of web components. By having this web standard way to build a component, frameworks don't necessarily have to bring along a totally custom model to be able to get things like CSS encapsulation, like DOM encapsulation. So with Polymer 2 particularly, where all the things we've been doing to make it more interoperable, to strip away all of the Polymer-specific idiomatic things that you had to know that broke through that layer so that a Polymer 2 element is truly a custom element, it's going to be a lot, lot easier to interface Polymer 2 elements with existing frameworks. On the framework side as well, more and more frameworks have been evolving and shifting slightly to better support web components and custom elements. And I think we'll continue to see that in the near future from some of the big frameworks. And also, already there are existing kind of couplers that make it really easy to use framework X with Polymer element or framework X with web component. The bottom team was up here, they mentioned their Angular adapter, highly encourage you to check that out. That makes it pretty seamless to work with Polymer elements inside of an Angular application. So a lot of solutions that already exist, Polymer is making it easier for an opportunity to happen, frameworks are making it easier. I think this will be the continued arc of web components towards kind of seamless interoperability. So we're on our way there. OK, good. And reminder, again, we have these microphones, if you do want to get up and ask questions, don't be shy. All right, another question we have is, we heard from a number, we had partners here, we heard from a number of those partners that they ran into situations where they had too many components. So is having a MyApp element still a viable approach? When is the right time to create a component? Sorry, that's a bit of a few questions called jam together there, but it's a little. Well, yeah, sure, I can handle that, I guess. So I think this is a hard question to answer, because as with many things, there's not really one size fits all. I think it's perfectly fine to have one element that defines your application. If you're using the purple pattern and delivering a small bundle, the bundle for that is going to download and render quickly the resources. So that's pretty straightforward. I think in my talk, I emphasized that focusing on very specific, high frequency elements that you want to make as fast as you possibly can, having reasonable goals for those, and being careful in those elements. And I actually got some feedback, which was that the thing I was saying, do less and be lazy, actually sounded really hard. And so one thing I can say about that is that because we're using web components, the good news is that the hard work that anyone does is something that all of us can leverage. So that seems potentially good to me. So as long as someone figures out how to make a thing fast, we can all benefit from it. And then I think there's a lot of really specific questions that have to be answered in the context of your application. But from a performance perspective, I think just keeping in mind that the cost of the element should match the task that you're trying to have it do. So where you need to make a lot of things, make them as cheap as you can. So one thing you can think about it is that creating a custom element isn't free. You've got a tiny little bit of cost with every custom element that you have. So if you're going to just make a custom element to wrap a span, that's not really worth it. You could just put a class on that span, especially if you're going to repeat that span a lot on the page. But if it's a little bit of a sizable amount of DOM that it's hard to style and copy-pasting it in different places in your app is really annoying, that's a good place to put a custom element in there. Luckily, we never said everything is an element or anything like that, so we didn't encourage the wrong people. Yeah, we never made any DOM packages. We never did that. All right, we have a question back here, sir. This isn't exactly a Polymer question, but it's future-centric and it relates to our stuff that we do. What's with WebAssembly? When does that arrive in the real world? And what goodies do we, can we expect from that? Maybe perhaps related to Web Components and Polymer? I'm scanning the room for V8 people. There's one right behind you. There's Adam behind you. Yeah, you're sitting right next to him. I don't think we really know up here. No. WebAssembly doesn't impact Web Components that much. I mean, I don't think it really has direct access to the DOM right now, so. If you're writing a game, yeah. But he found his person, he's hunting them down. They're in the back corner. Standing up. Somebody move on. So this is a good question, because I see a lot of people, they ping me and they're like, I wanna make a thing like paper input. I don't, don't do that. As I've been doing a lot of accessibility work lately, I've realized, input gives you a lot in terms of accessibility and things like that. So the question though is, how do you leverage semantics when you're writing a component? So for instance, if you are trying to write something like input, and there are reasons to perhaps, you know, wrap some of these components. So how do I leverage existing semantics inside of a custom element that I am creating? And I think that might be a good question for Monica. Why do you mean exactly by leveraging existing semantics? If you were to redo something like paper input, how might you go about doing that? Paper input in particular is enormous.  So it should be 17 sub elements instead. What paper input does, because it wraps an input in its shadow DOM, it has to channel all of the properties that you could set on an input and sort of expose them to the paper input itself. So we have a behavior for that, which basically defines every single property that input has as a property that paper input can have, which isn't great. But if that's the thing that you wanna do, you can do that. The reason why I'm saying paper input shouldn't be like it is is because it should be something like paper text input and paper number input. And it could only have like three or four of these existing properties that it needs to pass down to the input. I don't know if that's answering your question. Sounds correct. We also try to, this is sort of tangential, but we try to mimic in our custom elements what the platform chooses to do. So paper checkbox has a lot of the semantics that input type equals checkbox has, for example. It doesn't look like input type equals checkbox, it has a completely, like, it's called paper checkbox, but it has the same sort of, it has a checked attribute, it has a fairly quirky value where it's on or empty because that's what the input type equal checkbox element does. And ideally we like it that you could replace wherever you're using input type equal checkbox with a paper checkbox and have the same semantics without you being freaked out about that. Yeah, and that's, honestly, I feel like that's one of those things a lot of developers overlook is semantics and especially how they relate to accessibility. This is about it. A lot of people are like, well, you know, I don't even know if I have any users that need this. There's about a billion people worldwide that have some form of disability. And so if you are creating a widget that already has an existing analog in the platform, you really need to make sure that you are adding back in all of those semantics and the proper accessibility and keyboard support and stuff like that if you're not gonna be using that existing platform element. Which is why, for instance, I often tell people, just use button, okay? Like button actually, it seems so simple. It does a lot for you. And there's a lot of stuff you probably don't wanna add in that you're gonna have to do if you need to turn that into a custom element. You totally can do it. And my friend Eric Bidleman has done a talk at the PWA Dev Summit on exactly how to do that, which is a great talk that you should all go check out. But remember, the platform is trying to help you here and give you a lot of stuff. So when we say use the platform, it also means just leveraging vanilla HTML where you can. I just add one more thing. Yes. So I just wanna come back quickly to the loss of is in V1 custom elements. I just wanna get back to that because this is one way you could in the V0 custom elements leverage existing semantics here. And doing it yourself with implementing all the accessibility of yourself is hard. So I mean, we on the team basically really like this idea of is and it's still in the spec and it's probably gonna be implemented in Chrome and we're arguing for it. It may evolve kind of one of these things. This is why we're not really recommend using it going forward for now is because the support may evolve. I think there's general agreement, my sense is, there's general agreement this is incredibly valuable to be able to leverage these capabilities. But the exact way that it happens is tricky and there's some nasty things about is like the, we actually engage then directly with the old legacy built-in elements like input and like input uses a shadow root and therefore you can't add your own. There's a lot of tricky stuff there. So, I mean, this is a little bit of a, there's still I think a little bit of a growing pain here that hopefully it will evolve relatively quickly. Oh, fight for the people to get is back, don't worry. So we have two questions, but I'm gonna hold you for just a second because this question is one that we get asked. This is probably the second most popular question. I really want you all on stage to answer this. How does SEO work with custom elements? Can shadow DOM content be seen by a search engine? You actually answered one of the audience questions. Nice. Yes, so, we do get this question a lot. It's not a yes or no. The short, yes is the answer. The short answer is SEO with Polymer web components is absolutely different than any other front-end JavaScript-based framework that you work with, period. Right now, no web crawler that I know of actually natively supports shadow DOM, so it's not even a question of actual shadow roots. You need for a web crawler to see your page, you need to include the polyfill anyway, so right now it's irrelevant, and now that web components are in the spec, I highly, highly expect that anyone who might build a web crawler for search would very likely probably look inside the shadow roots as it's part of the HTML spec and something that's gonna be used cross-browser. Well, I think the most important thing to acknowledge here is that crawlers run JavaScript. I don't know if everybody knows that, but the crawler will render your page internally as it goes. Yeah, exactly. It's a blog post on the Google Webmasters blog. I don't have it like the URL top of mind, but it's from maybe about a year ago where the team said, yes, that the Google crawler at least does run JavaScript for a brief while against your page, so if you can dig up that Webmasters blog post that's in there, which would give you time to bootstrap some components. Yeah, yeah, and so for obvious reasons, I can't go into too much detail as to how these web crawlers work or indexers work, but I do highly, highly recommend, if you're skeptical about how your site is getting indexed, I highly recommend checking out the Fetch as Google tool, which is part of the Webmaster Tools set, and what you can do is go in, give it a URL of your page, and actually see how Google's crawler sees your page. So recommend you do that. You can see, make sure that it shows up the way you'd expect. Another nice little tip is the site colon query is a very valuable query to use.  If you view the source of shop, you'll just see one tag and that's it, that's the entire DOM, but if you site colon query, you'll see that everything gets picked up by the crawler. So I highly encourage using that Fetch and render as Google tool in Webmaster Tools. Okay, you have patiently been standing, so you go next. Hi, I'm Sam, I'm from Brainlap, and my question is about supporting old browsers in particular, like Explorer. Is it still in plan or feasible? We support IE 11 and Edge. We still support 10 a bit, too. Mm. Mm. I mean. So Monica made that noise, you know, audibly. Steve made a much worse noise in his head. We want to end support for 10. We do not list IE 10 as supported on the Polymer website, if you had checked it recently. So, yes, so technically. Oh, God, we have a PMG transfer list. IE 11 and up is supported, we always used to support IE 10 until Microsoft end of life, IE 10 across most Microsoft platforms. And so we decided, well, if Microsoft can do that, it's probably a good time for us to do it too. But, and the reason that being is IE 10 support, because of some flakiness and some features, it adds a lot of complexity to the polyfills. So that's why we're like on the fence here, is that for most cases, everything should work fine. You might see a touch of flakiness, which can be fixed if you drill way down. If that's worth it for your set of users that are happened to still be on IE 10. So that's the end. Please do not open issues on Polymer elements if they don't work on IE 10 though. Don't want to fix it. Thank you. Thank you. All right, over here, question. Hi, I'm coming right back from PGS Software. And I have a question about, because Polymer 2 leveraged a lot of ES6 syntax. And you have your tolling. But in my project, for example, we are using a lot of Babel and everything. So we would want to make more custom builds. So, but I saw yesterday that you were using the getter-setted syntax, and using pro, adding the service worker by magic. So if I prepare the output from Babel, so transpilot, it would be still be able to add this service worker, and it will be work on Polymer 2? Yes, I mean, there's a couple of ways that we want to integrate compilation into the workflow. One is that the Polymer build library, the reason why it's broken out the way it is, is to let you plug in things like, go Babel or something in that pipeline in the appropriate place. It turns out that the type of compilation that Babel does to output ES5, generally preserves the ability for the analyzer to recognize that there's an element there. There's some cases where that isn't true. Like if you're using TypeScript with decorators, that would output something that's very difficult for the analyzer to recognize. So our general approach is that if you want to run analysis on your program, you want to do that before you've compiled it to make sure that it's looking at your original source. We're adding a compile flag to the CLI to kind of give you like a default good compilation via Babel and we're gonna add the ability for that to pick up the Babel RC file out of your project and take out what settings you need there. But in general, it should play nice. And the service worker, the way we determine what needs to be in your service worker is by crawling the HTML import dependency graph. That's not changed by Babel. So there shouldn't be any problems there. Okay, thanks. All right, I have a question for our product managers, Wendy and Taylor. What can non-Google developers do to get better support and feedback for issues and PRs for Polymer and Polymer Elements? But basically, a filing issue, how come it's not fixed? You can email me personally, it's Taylor Savage. I don't know. Thanks, Matt. Well, first of all, I really appreciate when you guys do submit feedback. So thank you to everyone who does that already. That's a big reason why we're open source. We love getting that feedback and PRs from other people. I mean, a lot of our channels on Slack, like we have tools channels, and those are smaller generally. So if it's tools related, Justin, Fred, Peter, they're in there. We've got some other channels up there. Usually we're on general pretty frequently. So if you've got a question and you might wanna stick that in there, you can get information. Contact us on Twitter. There's a bunch of ways. If you find like it's a pretty regular thing, feel free to bug us. And we'll get back to you. We'll try to. Yeah, the best way by far to get quick response on a bug is make it a really, really good bug. Meaning detailed repro. If you can get to it, example of even a JS bin that shows us, wow, what the bug actually failing. Those help us triage because we know that there's not gonna be a ton of overhead just digging down to a root cause. It helps us also just kind of get a feel for how serious you are about getting this bug fixed, in a sense, how much it's impacting your project, if it's worth actually putting that together. So obviously we get a ton of bugs on the Polymer project across our Polymer library, our 100 plus elements, our dozens of tools. I really do wish that we had infinity engineers to fix all the bugs all the time.  But when it comes down to it, we are still a small team of just people. And we have hundreds of repositories that have issues on them. It's really, really hard to manage. Yeah, yeah, so we do our best. We really do appreciate issues that come in. We're always looking for better ways to better processes to triage and get bugs fixed. And we especially appreciate the really detailed bugs. Those help us a ton. And if you're nervous about sending us PR is we really, really like PRs. So even if you're not super confident in your fix, you can be like, I've got an idea for this. It's probably not great, but it will work with you to improve your PR because that's much easier on us rather than starting from scratch, so. You know this is recorded, right? We're gonna be able to use that again, see you later. Thanks. No, I mean, longer term there's also, I think we've been doing a lot of things as a team, having our own element catalog and things that have sort of gotten in the way of the ecosystem that might otherwise solve some of these things. So I think you're gonna see us very, very soon. I mean, step one was just the beta of webcomponents.org, getting out of the way a little bit more and allowing the community to thrive and start to respond to things a little bit better too. Yeah. So again, it's taylorsavage at gmail.com. Right here. I hope there isn't a... I know. Probably is. Sorry, dude. Docs here. Probably actually his. He probably just gave away his personal email. Did you just doc's Taylor? We know Paul Irish is, so that's the thing about that. I think it's an Irish on GitHub on our issues. It'll be great. Right here. Right, hi, my name's Thomas. As a remark for SEO first, maybe the best advice would be use schema.org for the time being. Sorry, what was the question again? Not the question, but remind us with regard to SEO. So maybe schema.org is the answer for the time being, right? But my real question is about inputs and shadow DOM within forms, because when you have fields inside shadow roots, forms doesn't work. I mean, validation breaks. So does it really work? Will it work? Or maybe I'll just have to put everything in light DOM. Yeah, so the question again is native form element. I want to put custom elements inside of it. That does not work. WTF me. Rob, do you know anyone who knows about this? Yeah. I don't know. Anyone in the middle? That's my question. Get out of the way. So this is a seven part answer. No, I'm kidding. First of all, I actually just did a polycat. The outtakes that you saw this morning were for me trying to record two polycasts about exactly that using custom elements in forms. And the punchline for now is you can either copy the value that you want to a hidden input, because the form only cares about the input tag at the moment, and that's baked in the parser. It's kind of really hard to change. So either you copy your value to an input or you put that input in the light DOM. If it's in the shadow DOM, you have to somehow copy the value to the input if you want to use a native form. We are trying very hard to work and change the spec in this, but the problem isn't that it's not a spec changing problem as much as it's literally barked baked in the parser. So the parser will see a form and then only look for input tags. And changing that isn't exactly straightforward. Blink engineers have a panic attack when you tell them about changing the parser. I am desperately trying to add spec to this to make you be able to get input functionality. And again, the is equals attribute helps a lot with this because you could be able to extend the input tag and make your custom element basically fake that input tag which would make it work with forms. All right, we have like one minute left, so we're gonna go kind of lightning round here. I do wanna try and get to some more of these audience questions, but this one question is pretty important. How long will Polymer 1.0 be maintained now that Polymer 2.0 is a thing? Yeah, what do y'all think about that? As long as it needs to be. Remember, it's Taylor Savage at Gmail. Taylor, you know this is recorded, right? And I think we've hopefully made it pretty clear throughout the conference how much we care about upgrades and upgrade paths and upgrade cycles and making it as easy as possible to upgrade. We feel that pain on the Polymer team. We feel it within Google. We see it throughout the ecosystem. So we've really taken that seriously with Polymer 2.0 and all the tooling around it and hybrid mode and all the documentation that's coming. So we hope that the upgrade from Polymer 1.0 to Polymer 2.0 is fairly straightforward, certainly not. And I know many people mentioned about being around from the 0.5 to 1.0 upgrade, which was one of the moments where we really learned this lesson hard. So should be fairly straightforward to upgrade. I encourage everyone to try to as soon as possible. That said, we expect Polymer 1.0 to it's a huge dependency inside of Google itself. So we're certainly on the hook for supporting it for at least many months, years to come. I have one tiny addendum to that. Will the V1 web component APIs be supported in Polymer 1.0? That's not currently planned. But based on feedback, we'll see. Yeah, so that's kind of more gets to when would the threshold for V0 usage get low enough in Chrome? Because Chrome has shipped it, other browsers have not shipped V0, which is what 1.0 is based on. So it's really a question of it's still baked in Chrome. Right now, V1 is also supported in Chrome side-by-side. So you can use V0 and V1 on the same page in terms of web components, totally fine. So really that won't matter unless V0 usage gets to such a low point that Chrome can take it out its report for it entirely, which would be fairly well into the future. And just a technical note, I mean, one thing just to be clear, the V0 and the V1 specs are not hugely different, but they're different enough that frankly having both in play on the same page is just not something that makes sense to really contend with. So kind of having Polymer 1.0 have that sort of mindset of having to deal with both V0 and V1. It's just a world of pain we don't wanna try. And this might also be a good reason to look into hybrid elements in Polymer 2.0 if you sort of need that transition path. Okay, we are over time, but I would like to take one last audience question because you've been standing very patiently. So sorry, everybody else. If you tweet at Ask Polymer Summit, I will go back and try and answer all of those on the Twitters. Rob, you know this is recorded, right? That's fine. Rob Dodson and everything.  All right, yes, you. Hello, I'm Maxim from Best Buy Canada and we've talked a lot about performance optimization. And I would like to know is the purple pattern meant to replace completely server-side, any server-side rendered templated? Let's talk about server-side rendering. Well, I think server-side rendering is a really interesting question. Like, we need to look at how it actually relates to, you know, pushing less for your initial render. But I was actually talking to some engineers who work on another framework, Framework X. And we were talking about server-side rendering, and I have this analogy with that, where server-side rendering is kind of like data compression, right?  And it should be cheaper to use a component than to expand that component everywhere out where you use it, right? And so server-side rendering is kind of like decompressing your data, sending the uncompressed data over the wire, and then recompressing it once it gets to the browser. And this should be bad, right?  And this engineer said, yeah, you know, once we split up our application so that we're only sending what was needed for the first route, it was faster than server-side rendering. I think our challenge with web components is that we don't have an existing server-side rendering solution that we can compare against. But it certainly seems likely to me with the purple pattern. And if you're rendering as soon as you possibly can with the minimal resources for that route, that it's gonna beat server-side rendering.  So we need to measure it to be short, but that's my hunch. Thank you for that question. All right, that is all of our time. Please give a round of applause to our lovely panelists.


Market was down this morning, made it all the way back to the flat of yesterday, then came all the way back downtown. We get the NASDAQ down 1.9%, S&Ps are off 1.4, as well as the Dow Industries. Gold, gold contract down $6.50, trading out at $18.30. We got silver down 6 cents, $23.28, light sweet crude, that is a flat $89.68 a barrel, notes and bonds. The 10 years down 36, $125.25, that's on an ABC structure down, confirmed ABC down 124. You get the 30 year down a full point plus 21 ticks at $151.21 and the 10 year folks just reached a 2.02%. King dollar, King dollar once again couldn't hold the value. But it was up like 300, gave it up on price, 95, 962, euros at 114, he ends at 115.92 and the British pound is out here at 135 to 1 US dollar. Well, you know what I'm gonna take a look at the spy, what you're looking at is this.  We didn't make it to the high yesterday, you know, you're at, it's filling the gap from yesterday when we bounced higher, you're gonna need a lot more volume to go lower. I suspect the spy right now is at 449, you know, right about here where he probably wanna hang out. Tomorrow we might get a little bit lower with lighter volume, this thing's still not done going up. That's the way I'm looking at this right now, particularly, you know, it's the same type of setup, meaning it's using way too much energy too quick in order to give it up on price. That's what's happening out here. The NDX now is different. The NDX, you are going lower with an expansion of volume. So we're down 824, we're at 358, that is saying that the NDX, the 3Qs can get out of that 351 mark, and you're at 358 right now. We go to the gold contract, we take a look at the gold contract. It's a gold and the dollar is a nice setup. Why? Because what we have now is that you have volume, we haven't had volume.  Stay right there folks, come right back.


Good afternoon. So just start off this still preliminary investigation. There's still information is going to be coming out. We're trying to still put some pieces together. Where I should have started with this. Thank God Almighty that the law enforcement is okay and that our public's okay. After what I'm told this morning this afternoon and what could have unfolded could have been much worse. I'm going to go a little bit further into this, but you know, things were slow, they're methodical, but our women and men were professional in everything they did. You know, we weren't going to rush into anything because at the moment there was nobody hurt. We wanted to make sure that things are done properly. And that's what we're very blessed. Everything worked out very well for law enforcement. It's a sad outcome for one individual's family, but at the same time is for what he did. It could have done. It could have been way worse for those that were innocent people out there. So I want to start off on with that GEPTLE. We have a special agent in charge, Mark Brutnell, Tampa Police Chief Lee Barkal. Seth Ferrell's Police Chief, Derek Brewer. U.S. Marshals were involved, the Pasco Fire Rescue, Hillsborough Sheriff's Office, their EOD was here for technical support. I also want to thank Lowe's. We're in the parking lot and also he talked about a great community in Pasco County. Lowe's came above and beyond to assist us because we were out here for a long time today. So thank him for that. The suspect in his case is Alfredo Luis Rodriguez. His date of birth was 22592 and he was 31 years of age. And the location was right up the street at Ruth Avenue 301. This morning, the Tampa Bay Marshals Task Force assisted. They were called out because Mr. Rodriguez had a couple warrants. Inactive Thony Warrant, Pasco County for criminal mischief. Inactive Hillsborough Warrant for a VOP out of Grand Theft out of Hillsborough and Provation for Grand Theft in another location. But the primary reason was he was a suspect in a homicide. And so because of those warrants, we wanted to bring him in and the agencies that were involved wanted to talk to him about the homicide that he was possibly involved in. He had a long history. He was arrested for resisting with violence, battery hit and run, DUI, and leaving a scene of a crash. So this is somebody that's been involved in the criminal justice system for a few years. Around 645, the Pasco Sheriff's Office detective who was on the Marshals Task Force notified dispatch that he was going with the US Marshals Task Force to the location to serve the warrants. The notified patrol, as they were going up, they go to the door to knock on it. And the suspect's girlfriend answers. They quickly take her from the scene. She's pregnant. They wanted to get it out there because they were afraid he was going to be violent, which their instincts proved to be right. Very shortly after he starts firing rounds at the task force. At that time, a member of the Tampa Police Officer who's on the task force returned fire. Pasco patrol starts hearing us over dispatch. They start arriving on scene. The suspect then continues to fire rounds. At one point, a Pasco deputy returns rounds on the suspect. So this just leads to the very beginning. This is still seven something in the morning when this is going on. You know, as this is going on the rest of the day, our members go out there. Our SWAT team gets activated. Hodges negotiation gets activated. All these agencies here today put forth all the effort we can for a peaceful resolution. You know, any type of things, I get it. We could be cowboys and run in there, but that's not what we were supposed to do. We are trying to find a peaceful resolution because what we did not want is one of our member shot. What we did not want was one of our canine shot. And what we wanted to do is find a peaceful resolution in this situation. The other one too is we very quickly, while this is going on, was remove the citizens in the area that we felt were at risk because you never know where those rounds are going. Those rounds don't have names on them and they could hit anybody. So we wanted to make sure they were safe. So as the state was going on, our tactical team went out there, house negotiation, our drones, everything we could utilize to have a peaceful resolution. So we were going through this methodically and the suspect was talking to us throughout the time. He was on or off the phone. So we know that in the beginning he did not incline to us at all that he had been shot, no injuries. He was talking to us. Around 1245, we know there was one room left that he was in, our robotics, drones, everything we were trying to do to get back there. The women and men, the SWAT team, everything was going forward. We were trying to still negotiate with them. However, at some point we were able to make entry in that room. As we made entry, we realized that the suspect had possibly self-inflicted gunshot wound to his head. So we're still working on that right now. But I can tell you that there is a resolution to this situation. But I want to go back to one of the things I said earlier. We are blessed by God that nobody, law enforcement was hurt, no citizens were hurt, none of our canines were hurt. The other one too is we're blessed by God to be here in Tampa Bay. To be here with these outstanding women and men in law enforcement and public safety, our fire rescue out there, everybody. It's a sad day when these things happen, but at the same time is that we come together. And I get these criminals now, they seem like they're being more violent towards law enforcement because they see what goes on across the country where laws aren't enforced. Law enforcement can't do their job because there's politicians out there that are holding them back. It's not going to happen in Tampa Bay. It's not going to happen here in the state of Florida. We will enforce the law. And so there's a message back out there to criminals.   That's what we're trained to do. We will make sure at all costs that our community will be safe. And that's what all the women and men up here that we will defend is the fact that we will not be like other areas of the country where criminals run those neighborhoods. In our community, in our state, we're going to make sure law enforcement and the good citizens still run our communities. So with that being said, I want to bring up Mark Rutnell, the special agent in charge of FTOE. Thank you, Sheriff. Sheriff said Mark Rutnell with FTOE here in Tampa. Pursuant to a mutual aid agreement that we have with the Marshall service, we are here conducting a criminal investigation into the use of force, deadly force, by a member of the Tampa Police Department and the Pasco Sheriff's Office. I can echo the Sheriff's comments that today was a classic example of great restraint and patience. I live in this community, so I was very proud to watch the collaborative effort of all the agencies that are here today. The partnerships are immense, well, old machine, but again, I go back to the restraint and the patience that was showed by all the agencies here today to hopefully end a peaceful resolution. Unfortunately, this individual chose this path. These officers were doing their job this morning, and he fired upon them, and they fired back. And that's why we're here today to conduct that investigation. It's a long process with a lot of work to do today, but we'll get it done and we'll present that to the State Attorney's Office for review. Thank you. Thank you, Sheriff. Please call the Chief of Police for Tampa. The Tampa Police Department plays a significant role in the U.S. Marshall's Task Force. And as the Sheriff alluded to before, the U.S. Marshall's Task Force goes after the most heinous criminals. They are the best of the best, the most highly trained, that go after our worst of the worst. And in this case, we had an outcome where the citizens and the officers were okay. Obviously, that's our main concern. And the officers, thank God, they were shot at. We had our officers that were shot at and one of my officers were turned fire. And thank God, they were not hit. In this situation, we owe that extra training to the U.S. Marshall's for their extra training that they provide for our officers to do this. The community and our Task Force and all of the agencies that are out here at the Tampa Bay area, like the Sheriff alluded to before, has an excellent working relationship with all the other criminal justice stakeholders and the community members themselves. And that's why we're at this resolution that we're at today. So thank you. Anything, any questions? Sheriff Gino specifically, was it one of the robots or a law enforcement member who found him in that room that you mentioned? Yeah, this is a separate investigation. We had numerous different robots that were going in there, members that were going in there, but go back to it. You know, we're in a command bus. We're listening to what's going on.  And so, you know, we're going through our lines. What do we do? How do we do this? And one of the things that came up was about, you know, our canines are trained or swat some tactical canines and we're going to send the dogs and we're like, no, hold on. Let's get those robots in first because we all agree. We do not want to put those dogs in harm's way. This guy's already shot at law enforcement. He shot at people. We don't want to harm a dog either. And so, you know, sending their robots in, sending everything in. So I'm not sure if we saw a mirror that they were able to get into that room or was it one of the robots that got in. But this is where I go back to, you know, public safety isn't cheap. We deal with protecting lives. And so any tool possible, we can have resolutions like we have now where 10, 15 years ago, that swat team would have been kicking indoors going through. And now we, you know, the professionalism has immense right now. You know, it's been always great. But what we can do with technology, it gets even better and we can make things safer. But at the same time is, you know, they cost money. But no matter how much hardware we have, how much software we have, it always comes down to the human heart and the human head. And those are the things that came together to say, hey, let's get in there and make sure everybody's going to be safe. And like it was looted before by especially in charge of Brunel, he chose his own fate. He had hours to come out on his own.  But let me end this peacefully. He chose his own fate. Any general thoughts on what he said in the conversations that he did have over the phone? I don't know. Whether you said that house of negotiations or what he said to other people that were on the phone, but so sorry. Yeah, so that I don't want to get it's not a Pasco case. It's one of jurisdictions and with the outside county. So they were still going through some things now. So I don't want it. I don't want to interfere with their investigation. It's not a Pasco Sheriff's Office investigation, but we were out there to assist with the marshals task force to go out there to apprehend this person to bring him in for questioning. It was a jurisdiction in Tampa Bay. A couple of lab booms coming from the house and we saw the battering ram. And yeah, so if you heard a boom, that's the flashbangs.  So we just want to make sure he's alive. There's some points where he got up. You know, our people knew he was walking around. So we knew, you know, he was still alive at that point.  We had to get through some windows to make sure that we can get the tear gas in there. Unfortunately, it probably wasn't the best structure to begin with. Structurally sound building. So you take a window and things start falling. The part with fire rescue, and I give Chief Perez credit, this is probably this is probably the first operation we had because the evolution of our partnership together with Pasco Fire Rescue, the medical side, the tactical side, they were out there for several reasons. One is they've got forbid somebody got shot on our side. We were able to render eight quickly. If the suspect came out and he was wounded, they were able to render eight quickly. The other side of it is if, you know, you don't know what this guy's doing inside. You don't know if he's going to start, if he has gasoline, he's going to start a fire. They were there to make sure that they can turn that fire off, you know, put water on it, put foam on it, do something like that. So that's the whole part of slow methodical, but having the right pieces in the right place. As I said, there's times we have to go in hastily and take care of a situation. There's other times like today where we can just methodically go through it. But it was not the best structurally sound building to begin with. And so we have to make sure that as we go through it, it was safe. Right now with fire rescues going out there for and we appreciate Chief President team is making sure that that building does not collapse on forensics as they're going into that situation now. Yes ma'am. Okay. It goes back to the point that this guy was shooting rounds out the window at anything that moved. And so it wasn't like he shot us at one point and then it kind of ended. This guy was continuously shooting at us for a long period of time. And so that's why we have to go out there to get those neighbors to say get out of that situation. It's not safe. And so I, you know, 100% those homes out there, you don't know what one round goes. You don't know who's walking their dog. What kid could be standing on a school bus? You don't know those things. And that's why all these situations are extremely scary for our citizens out there. For ours, you know, and as I said, we train all of us, all our organizations, we train for these bad days all the time. Because think about it, it was a violation, VOP for grand theft. You know, yes, he was a suspect in a homicide investigation.  But at the same time as, Hey, just come out, talk to us. I can imagine the task force members do this all day long. They go pick up people all day long.  We talked to several neighbors that were displaced during this year. How many people were in this area? I apologize. I don't know exactly how many. Yes, sir. We were at this address last month and the server warned on this man. Is this the first time you tried to serve another one on him since that time? I don't know when was the last time I know we were out there previously. I'm not sure between that time and this time if this is the first time we make an interaction with them. But you know what, who knows what you never know what's in his mind. And now we never will as to what he thought we were going for today. Maybe he was the prime suspect in a homicide and he didn't now he thought the walls were closing in on him. Maybe there was other crimes that he was involved in that he didn't know and he thought we knew. So you don't know how people react. And a month is a long time in law enforcement. You don't know what crimes or things people may have done in a month. But when he came to that door this morning, yeah, and he probably thought the end is coming. And unfortunately, he put the pregnant girlfriend at risk. He put his neighbors at risk and put law enforcement at risk and he ended it on his choice, not ours. All right. Appreciate it. Bye. Thank you.


Tena koutou everyone my name is Luke Percy I'm the head of web CMS at Catalyst While I myself might be new to the Drupal community Catalyst definitely isn't We've been giving back, you know giving back to the community is important to us and Catalyst developers are actively in helping Drupal's Issues queues as well as other external sites like Drupal answers Catalyst also contributes beyond code modules and Documentation such as hosting the Wellington Drupal meet-ups We're credited on over 30 issues in the past three months, but you can come check us out on Drupal.org if you want to see more I'm proud to introduce today Gian while she will be doing a talk on mobile accessibility testing mobile sites for accessibility something that we value at Catalyst as well and Let's without further ado get into it. Hi. Thanks everyone. Thanks for attending and thanks for our great session organizers And event there. I'd like to talk about mobile accessibility today now a lot of you probably aware that there are There's WCAG requirements around accessibility, so you know, why can't we just use them for mobile? And basically, I'll just give you a bit of a history. So the ICT accessibility testing symposium in October 2017 this is a conference that occurs once a year It's specifically aimed at accessibility testers and at the end of the conference we have what's called a town hall where we you know ask the Testers and the people in the industry. What is it that? I Really needs to be addressed in the accessibility industry that hasn't been, you know, really properly addressed and in the 2017 session the overwhelming majority of people talked about mobile accessibility testing and so the problem of course with Mobile is that WCAG wasn't written for mobile. I spent six years with the W3C Contributing to WCAG 2 and you know, it was released in 2008 Of course the first iPhone was released in 2007 But of course the majority of the work was completed in 2006 So we really just had no concept of how you know people would use mobile to access the internet So what we did first off in 2018 was the chair of the committee was we Amalgamated the various different mobile guidelines from around the world. So the BBC mobile accessibility guidelines The past yellow group had one as well We accessibility OZ had one and we also incorporated DQ's Accessibility guidelines as well. So we kind of incorporated all these into one set and we were really looking forward to Not having to do anything more again because when you WCAG 2.1 would be released in June 2018 So, you know, we thought this was a one-and-done kind of deal now Just I'll just sort of take a step back and explain why mobile is different to desktop Mobile has a lot of native screen readers Such as a talk back narrator voiceover It's very different to the desktop environment where people, you know, don't like the screen reader screen readers That are available like Jaws and go off and build something like NVDA. You really can't do that on mobile. You're stuck with the the mobile features that are Incorporated in the mobile device that you're using and not just screen readers. There's also volume control haptic, you know vibrational notifications Text-to-speech speech recognition zoom, etc and a number of system accessibility settings that you know people with disabilities Will use but a lot of people without disabilities or without Defining themselves as someone with a disability would use as well such as font size touch and hold delay screen rotation High contrast assistive touch and mono audio. And so you've got a lot of more people using these settings even if they aren't actually you know seeing themselves as You know having a disability and these settings can really, you know play havoc when it comes to mobile sites So let's go back to WCAG 2.1 But before we go to WCAG 2.1, let's talk about WCAG 2 So WCAG 2, yes Success criteria are applicable to mobile, you know, old attributes are required on images whether it's on a mobile site or a desktop site However, not all aspects of mobile accessibility are specifically covered by WCAG 2 So for example, although WCAG 2 requires sites to be accessible to the keyboard user It does not specify that it should also be accessible to the touchscreen user Which of course is a major requirement when it comes to mobile So 2.1 was released in June 2018 And it does address more criteria relating to touchscreen pointed gestures Sensors and small screen devices. However, it still doesn't really cover all the user needs related to mobile accessibility And if you ever have anyone ask you well, you know, what is it about 2.1 that doesn't? You know meet the real criteria that you know is needed in the real world The best example is touch target size So we've all had cases where we've gone to touch something and it's too small, right? And so you pinch zoom to make it larger or maybe you activate something that is close to it because everything's just too small Now that's a real problem for people with disabilities. So it's really important that You know that things have an adequate touch target size or there is an ability to say pinch zoom now That requirement is in WCAG 2.1 But it's relegated to level AAA and as I like to say level AAA is where success criteria and go to die So that is the problem is that yes, there is a really important requirement But people aren't necessarily going to even come across it let alone implement it in 2.1 So another thing with WCAG 2.1 requires Page variations so now this is actually required in 2 WCAG 2 as well But I just thought that I would Address it now because it's something that a lot of people get confused about so low vision users who use the zoom function Inherent in the browser often are restricted to a mobile view of the site on their desktop So as part of WCAG 2.1, you must be able to zoom to 200% and access all the functionality and everything as required And so that functionality is not removed just because you're increasing the zoom size And this is an example here, and I just want to say that it has been fixed, but previously in YouTube The uploaded notifications button on the desktop site were visible at 100% screen size But not at 200% screen size now Why would that be that's because they basically if you hit 200% screen size on a desktop You triggered the mobile view of the the site and so they assumed that you're looking at YouTube through the mobile site now Why would you get rid of your upload and notifications on the mobile version of YouTube? Because people would assume that you'd use the YouTube app to upload or you know access your account So therefore you wouldn't have it on the site However, of course people who are using the desktop version at 200% aren't ever going to be able to access those things So this is an example here Uploading notifications visible at 100% and at 200% they disappear So that there is a real problem and is why it's really important that whether you whether you have a mobile site or a desktop site that you provide all the same functionality on both versions of the site and Whether it's responsive or you have m.sites doesn't matter you need to have all the same functionality now You can hide the content if necessary, but you must have you know the same ability to do all the same things The other thing that was in WCAG 2 but is really important now with 2.1 is Accessibility supported so basically it means that if there are accessibility techniques inherent in a Device or a technology say PDF or HTML you must use those accessibility features And so that means that basically, you know if you're using a PDF you need to you know Tag that PDF But basically what it means for mobile is especially when it comes to native apps You really need to actually do testing with assistive technologies because there's really no other way to determine whether those Native apps are using the features inherent in the system Now so this methodology covers a lot of things But I just want to say it does not include things that are already in WCAG 2 So for example, it doesn't say hey your images need old attributes your headings need to be coded because that's in WCAG 2 But it does include the new errors that are listed in 2.1 and that's because you know some Some countries or some organizations might still be meeting WCAG 2 But want to make their stuff mobile accessible now. It's very clear when something's a 2.1 requirement We have made some minor changes. So we we disagree with some of the the things that 2.1 You know has come up with but we make it very clear in the methodology what that is So basically the most important thing to remember is that you really need to test with real devices So this is back when you know, I used to travel the world before COVID And I started doing a whole lot of international travel from 2014 and so, you know, it's a 14-15 hour flight from Melbourne to LA and You know, there'll be no Wi-Fi because it was back in the Dark Ages and we'd land on the tarmac And I would be able to access the LAX Wi-Fi however on this LAX Wi-Fi page it says This page will redirect so content doesn't really make sense to have here and all of a sudden I don't really feel safe giving you my email address or my credit card details or anything like that So how did this happen? This happened because someone was testing on a desktop They didn't test in the actual environment on an actual device so that's something that's really really important you must test with actual devices and If you have location Things you need to test in actual locations as well So back to the story of the methodology So 2018 the Committee reformed and said well actually as a committee. We're quite unhappy with how we can't 2.1 address mobile So they we decided to reform the committee and Split it into two groups one for native app Mobile testing guidelines and one for mobile site Testing guidelines that I was voted chair for both those groups. So we worked over the next year or so developing methodology a methodology one for native apps and one for mobile sites and they're both very very similar But today I'll be talking about mobile sites So basically the first thing we determined was the testing methods what testing methods should we really undertake when it comes to Mobile sites, so we decided that there were four main testing methods one was devices So testing on mobile and tablet devices Secondly was test devices with assistive technologies. The third was responsive windows So testing on a responsibly sized window on desktop and then also testing on desktop now You know notice there's no simulators there. There's no Kind of automated testing tools or anything like that we really decided as I mentioned before simulators are not good enough, but the Testing tools that are available really aren't robust enough to be able to rely on them at the moment So the methodology itself has five steps The first step is identified devices. The second step is identify site type and variations The third step is test critical issues the fourth step test Mobile specific issues and the fifth step test mobile assisted technology and feature support and the reason why I've highlighted step 2 Identify site type and variations. That's the only difference between the mobile site testing methodology and the native app Testing methodology is that that step is completely different when it comes to native apps There are different examples and things in terms of issues as well, but you know, that's where it really differs So let's move to step one Identified devices. So the recommended devices and browser combinations We identified was iPhone with Safari iPad with Safari and an Android phone with Chrome Now you can use a Samsung phone But if you do use it do not use it with the internet browser that comes pre-installed with Samsung phones Because that's very indicative of what people will see on Samsung phones Whereas if you use Chrome on Samsung, that'll be much more indicative of what everyone on the Android Devices will see And so it also when it comes to choosing your devices Definitely have a look at your statistics other things to consider Things like an Android tablet for example a Samsung Tab A or a Chromebook using Chrome again and alternative devices such as a Kindle device if you have Content that's specifically going to those alternative devices We're recommending testing on the latest version of iOS and the latest two versions of Android and of course where a site is Directly aimed at people with a particular kind of disability including assisted devices, you know used by those people So if you have a site that's specifically aimed at people with acquired brain injuries, for example You're going to specifically want to test with things like dragon naturally speaking You know and things like that because those are the kind of technologies those people will use and You know, I've said it before I'll say it again. You need to meet with add to and this methodology You know, you can't just get away with this methodology The second step is the site type and the variations of the page So the first thing you need to do is identify if the site is a desktop M dot or a responsive site And if there's a site is responsive are there variations of the page now? I know this is a Drupal conference So, you know, you probably all know what these terms are but I'm just going to go through it just in case So the desktop websites They only have one display whether viewed on desktop mobile or tablet M dot sites They have a particular display for mobile and tablet sites now if you have an M dot site You basically have two websites the M dot site needs to be tested against WCAG 2 on Desktop and WCAG 2 and the mobile testing methodology on mobile the And the other site also needs to be tested on both as well So you're actually doubling the amount of work that you need to do because if you think about it The M dot site is completely different site And don't think just because you've got an M dot site that people won't look at the desktop on your mobile device Or they won't look at the M dot site on your desktop Because they will they will always find a way and we also have a clause in this methodology that you can only Force users depending on to a certain You know responsive site or an M dot site versus on screen size not on device or anything like that because there will be people That absolutely want to look at the M dot site on desktop at 100% zoom or want to look at the desktop site on mobile And you don't want to stop them from doing that And then of course the one that we really should all be doing and is actually a requirement of WCAG 2.1 is Responsive websites and hopefully that's what you're all doing. So an example of a desktop site here This is the Australian National Botanic Gardens I just had to include this because this was the first website that ever went live in Australia It has 49,000 pages not a single web page that has ever gone up on this site has ever come down I do not recommend doing this when it comes to your websites But basically if you look at this on a desktop and you pull You make the browser Thinner you see the site doesn't change at all Whereas this is a desktop versus an M dot site. So this is a Sephora site You can see you've got your navigation along the top, you know, it's nice and brown Etc. Etc. And if you go to the M dot version, you'll see it looks completely different it's blue you've got your hamburger menu on the top left etc etc and In a mobile sales sized browser on desktop, you will see that they look completely different and Then of course, you've got the responsive site So this is the accessibility odd site on desktop. You've got your navigation along the top And then when you make it smaller the navigation changes the services change nothing really disappears It just all re-reformats as required So the next step is to test the critical issues So one of the things that we found really early on is that there are a whole lot more traps on mobile devices than they're on desktop devices So what is a trap a trap is where a user is trapped within a component and cannot escape without Conclosing the browser or the app think, you know 2012 Firefox video players A lot of people would keep, you know tab into the video player and couldn't tab out The only way to escape something like that if you're a keyboard user is to close the browser and start again So basically we identified things as traps where the only way to escape from the trap is to close the browser on your mobile You know or the native app So we found quite a few the first one was the exit trap ensure There is always an accessible actionable item e.g. A closed button that meets color contrast requirements or has an accessible name That closes any feature that overlays the current page such as a full page ad And so this is an example here Where the ad actually overlays the entire page and the only way to really close this ad is to close The app and start again This is an example for a website We've all seen these where it's got a pop-up that's trying to sell you something and the only way to close the pop-up is to hit that small Close button, which doesn't meet color contrast requirements or touch target size requirements And so, you know, basically you're stuck. You can't go into the site. You can't escape etc Swipe scroll traps ensure you do not override standard mobile touch functions swiping scrolling etc on the majority of the page so basically I don't know what I just did Computers so basically This is an example where You scroll down to the bottom of the page and you can't scroll up And the only way to get to the top of the page is to actually hit that little arrow at the bottom right and You know, everything else is disabled and of course that little arrow in the bottom right doesn't make color contrast requirements And you know, it isn't really understandable This is another example And I call this a zoom of doom. This is being fixed. This is one of the first errors I ever found but basically if you this the map takes up so much of the page that you have to hit these Tiny areas of white around the edge of the map to scroll the page. Otherwise you scroll the map Now a lot of people are finding ways around that now by Having like the two finger scroll and things like that, which is great, but we still see these occasionally the headset trap Headset users must always be able to pause media audio or video content by using the pause play control on the headset applies to screen reader users and headset users This is an example here where you're on a website a little video pops up in the bottom as a touch user You can activate the mute Icon but as a headset user or a screen set screen reader user you you know activating the pause button will just pause the screen reader not that Video content and so basically they can't hear their screen reader. They can't use the rest of the page and Lastly a layer trap. The user should not be trapped on a non-visible layer This applies to all users, but it's mostly encountered by screen reader users This is an example here where you open the Hamburger menu and the focus for the screen reader user or the keyboard user Stays on the page underneath so they can't access any of the menu information or close the menu So let's see an example from the document. So Here is touch gestures. So any touch gesture must have an alternative accessible actionable item And this is very similar to success criterion 2.5.1 in pointed gestures. Sorry pointed gestures in 2.1 So examples of touch gestures are things like swiping up and down or left or right Dragging up and down or left and right Double tapping tapping and holding tapping and swiping to pinch zoom and press and long hold And so the alternative accessible gesture must meet with add to or 2.1 Meet change of state meet touch targets meet inactive space meet native UI meet removal of touch And so basically the examples of alternative accessible gestures that are just inherently Accessible are things like a link a button a drop down, you know or a separate page with functionality So each requirement has a section that's called about this requirement which explains why we need to follow it So I'll read this to you now This requirement is particularly important for screen reader users For example, if you require your user to swipe right to complete a purchase when the screen reader is on the swipe Right gesture moves you to the next focusable item and doesn't complete the purchase You must be able to perform the same action by using a link and up and down swipe or some other gesture This note this requirement is similar to the exit trap requirement However, the failure of the exit trap requirement is the user can't escape from a content from content or a page Whereas the failure of touch gestures is that user can't choose content or a page or that as in they're not trapped And so we also have a section on how to test So we so basically you identify any site controls if they require any of the following gestures Is there an accessible action an actionable item provided as an alternative? And then we talk about the controls that are problematic. And so this is an example here Of something that is a pass of this requirement. So here you have We've got a series of top stories and the heading indicates So you can tell that there's more content by swiping by the fact that the content is cut off on the right-hand side But you can also see there's a link that says see more and if you activate that link It goes to a page that shows you all that content Another example here is the Google weather and so you can actually drag the weather to a particular time And I'll tell you what the weather is going to be but you can also just tap on the time as a link And that will tell you what the weather is So you can find these these resources at the on the accessibility odds website So I'll just show you now where you find them So basically this is the home page. I will and if you go to resources then Mobile testing you'll get the introduction information on Various different things and then the different methodologies. So this first document is the actual methodology, etc I think, you know, just the WCAG 2 requirements Or the equivalent of the WCAG 2 or 2.1 requirements And then you've got a second document about mobile site testing which talks about how you choose devices You know the assistive technologies how you choose site types and variations of a page as well as capturing errors And then there's basically these are the test case documents or the equivalent of success criterion So you've got the critical test cases Then the just the standard mobile test cases and then the test cases for assistive technologies and mobile features So I'll just show you the document now So this is the document For mobile site. This is the critical test cases document and so basically you have You know the information about the exit trap who it applies to about this requirement We talk specifically about timed ads and a section on how to test non-timed features how to test timed features And then we have some examples as well So we do that for each one of the methodology requirements. So there's heaps of information and you know, lots of things that you know, you can look at in terms of examples as what to do Now we are actually reforming the mobile accessibility committee because 2.2 is probably another six months off and where you know we've learnt from our mistakes when it comes to 2.1 and We have learnt that we can't necessarily rely on the W3C to address these requirements And I just want to say that this is not actually unusual for the accessibility Industry before the W3C Developed WCAG that there's actually a committee of interested accessibility Specialists who wrote WCAG and that basically got just past wholesale to W3C They made some minor changes and that was WCAG one So it's very common for the accessibility industry to sort of you know stand up in this way And I mean the BBC mobile accessibility testing Methodology was released in like 2012 2013. So, you know, as I said, it's very common for the accessibility industry to do this We've seen it with non-ICT things as well EN 301549 really is very much is the European accessibility requirements and They have taken on board WCAG and then gone that step further and applied WCAG to things like photocopiers and things like that. So as I said, it's very common for the accessibility industry to do this and We are very aware that hopefully at some point the W3C will take notice of us and Incorporate some of the requirements. I have staff We're a W3C member and I have staff on the WCAG working groups So and there are other people on the committee on the working group So it is something that we are, you know, trying to get the W3C involved in now This is also I just want to say the committee Was consisted of people from all the largest accessibility All the major accessibility companies around the world But we also had say mobile developers who didn't know much about accessibility But who could assist us in terms of, you know, why does mobile site do this? You know, why does it show this versus that etc. So we would love to have you involved If you don't know anything about native apps, that's fine. We're going to be continuing the separation between the two the two committees and So we basically will probably be a two-hour meeting every couple weeks with probably two to four hours of work outside the meetings And we're hoping to get something done in the next six months So we'd really love you to join us and honestly if you feel like you don't have experience The fact that you are listening to this is in, you know, enough experience Sometimes we just need to go out and, you know, do research and I learned a lot about mobile accessibility Just being on these committees. So please do reach out to us The email is enquiries at accessibilityos.com or you can email me directly gian at accessibilityos.com and I will hand over to Luke now and let's see if we've got any questions That was great. Thank you so much So I Haven't got any questions and chat yet, but I had a few prepared so In in the mobile space, what are you seeing is the most common, you know Simplest things that we could be addressing that you're seeing a trend in that we should be looking at first That's a great question. Um, I would say Design, you know, like people who design mobile sites and native apps are designing on, you know, massive desktop computers You know massive screens and they really don't know how it's going to translate into such a small screen So I think that it's really important that you get your color contrast, right? Because, you know, gray text on a white background is a bad idea I don't I feel like I've been saying this 15 years gray text on a gray background is a terrible idea Like and I'm really small, you know small things people can't read You know people can't click on etc So that would be one of them, but the other is use the native elements whether they're HTML Whether they're in the native app or things like that use the native elements because they always have accessibility in built If you have to create a new sparkling bat see, you know User interface component you are going to have to add in all that accessibility and the fact is is that even if it looks okay to you As soon as you, you know change text size or the color contrast or whatever It's going to go wonky. So use the native elements. That's probably the biggest thing that you can do nice and Also, it's not Important that an app looks the same on an iPhone as it does on Android because the native components are going to make Things look differently. It's much more important that you use the native components Than you try and make the app look same the same between the two devices because people are often You know this their iPhone users and their only iPhone users or their Android users or their only Android users So so then they don't swap between the two I myself have an iPhone and an Android phone for testing And the differences between the native UI elements are not major enough to really confuse anyone But people are really not swapping between devices like that Nice Something I'm seeing in the industry a bit is bilingual on page Yeah, have you seen a lot of that and in terms of getting accessibility issues from having multi-lingual? Content in page like on the same screen space I haven't seen anything that that's has caused problems, but that we did talk when I was Working on we can't to about left hand languages versus right hand languages and how that can really you know mess things up So that can that's something to keep an eye on Yeah, it's just yeah, just make things just that little bit more difficult What I will say is that the I haven't looked at recently but six months ago. I looked at the Google Language change feature so you can put it on your website and say hey change all the language to Spanish or or whatever And that feature itself is not accessible. So I would say It's less important that well, it's not less important But it's it's important that you have the ability to change the language or choose the language and make that ability accessible And then you need to sort of test both in terms of you know how things you know layout properly and what happens if someone you know You know increases the text size or something along those lines or uses a keyboard or something like that We do have a question here from Andrea think so do you need physical devices to test the accessibility or online tools sufficient for that You really need the physical devices now. You don't need to go overboard My team and myself we have one iPhone and we have one Android device each so you don't need to have like 15 you know, so I we We test on the latest version of iOS and we've found that it doesn't really matter if you're testing an iPhone 10 or an iPhone 11 or an iPhone 11 max or whatever there might be some functionality Issues but they're not accessibility issues. So, you know, if you you really only need to test on one iPhone iPad is different again because of course we've got iPad OS now So it's gonna be behaving differently. So you need an iPhone and an iPad and then the Android devices as I said as long as you're testing on the Chrome so far on the Chrome Browser you should be good to go. But the we have done a lot of Looking at Simulators and it just is not the same. They do not behave and especially when you start Throwing in accessibility features like increasing tech size Or the simplified view on Android Chrome to look at, you know, just the text of the Of the site those things just do not get replicated Properly on a simulator. So you really can't use a simulator now I don't I don't think that I'm not commenting on whether you use a simulator for functionality testing, you know Whether things actually work or not, but for accessibility testing, you really only need You know an iPhone an iPad and an Android device and an Android tablet if you want to go that far But yeah, so simulators you really when it comes to accessibility you cannot rely on simulators unfortunately The expert spoken all right Yeah, thanks for the explanation, that's great In your view which organizations have great mobile accessibility Good question Apple Yeah Google Also, and I will say so there's there's we looked at there's so many different accessibility features but one of them is called reduce motion and Basically what that does is it's it's supposed to on a site or a native app Try and like reduce any kind of movement and this is really important because Movement can be really difficult for people with ADHD in some cases that can trigger epileptic fits So you really do want to reduce as much motion as possible and we found it's so difficult to find a good example Well an example of someone who had accurately used reduce motion on a website and the only people that did was Google so and they had a set they had a It was Christmas a year or two ago and they had some kind of like Actually a sort of like a almost a VR experience where you you know went into like a Straight in London and you looked at the different Stores and then you went into the store websites and it had this beautiful kind of flowing effect But you know if you turned off reduce motion, it just worked really really well But that was the only past version that we and it was done by Google. It was the only Past example we could find So it's it is something that you know, I mean, I've been in this industry for like 20 several years and I I really I started off Testing just not accessibility but just testing testing and you know, we had to test on Windows 95 98 there's 2000 Windows Whatever that stupid one was Windows me or something and it was just like and it was I remember thinking Oh my god, and now it's we're kind of back there, right? where there's just so many different device combinations and You know like when we released the latest version of the guidelines we released them at the end of 2019 and iOS had just released dark mode and Text-to-speech and we're like we don't have time to investigate all these and you know Like we like we will do it in the next round Because it takes a lot of time to actually document these features and they're often not very well documented You know, there's so many different You know features that you can turn on that anyone can just stumble across on a mobile device That can just make your mobile site just crash and burn that you know, it's just it's like the Wild West out there It's kind of you know It's kind of like where we were 20 years ago with with websites and you know We'll improve like as we do and then something else will come along and we'll be like oh my gosh We all need to figure out how to make VR or AR accessible or something like that You know, but it still is just kind of crazy out there and some people do it Really well, but they're the ones that have a whole lot of money That can start playing with these things. So yeah, I haven't seen Anything I like I found a lot of the examples for the methodology the pass and the fail examples and I must say finding fail examples or a whole lot easier than Passing than finding pass examples and there wasn't a website that I could Reliably go to and say I'll find a pass example here So really yeah, it's just Apple and Google are kind of the ones that that know what they're doing Awesome. Well, thank you so much. It's been great to talk to you and listen to your talk And I'm sure we'll walk away as better developers. I hope so Feel free to reach out to me with any questions and you know Let us know it. Please join the committee But if you know, even if you don't please use the guidelines and please let us know what you think like Oh my god, that's so much work or this sounds really good But I didn't really understand X that we need feedback to figure out, you know, we you know When you can't see the forest for the trees, that's kind of where we're at at the moment So we need a lot of people with new eyes to look at these and sort of say yeah, this is good Or this is bad. So love your feedback Awesome. Thank you so much. Excellent. Thank you. See you later. See ya