 OK. So if most people, it looks like most people are in. So we'll start right now. So title of the next session is, how do you defend the web by Shweta? And Shweta works at Opera. He's a dev relations at Opera and has been speaking and evangelizing web standards for a very, very long time. The internet is often under threat by many, many different things, most often marketing departments. I'm sure you've all encountered them in the past. And Shweta will tell us why it needs to be defended, what we can do to do so, and give us the tools and techniques to do. He also has many slides. So we'll. Yeah. Hi, everyone. So this talk is about how to defend the web. And I might take a little bit. I might eat into the Q&A time. So if you have any questions and there's not enough time, feel free to talk to me afterwards or on Twitter or email. So you might see there's this graphic of the revolver over here next to the web. And the reason why I had this is because every time I think about the web in various times, various years, I've noticed that the web has always had a gun to its head. Always. There's always been some kind of threat or the other when it comes to the web. Whether it was back in the day with native applications or, sorry, desktop applications. Then you had flash and silverlight and that kind of stuff, trying to take over the majority of graphical interfaces. And then you had mobile applications and stuff like that. It's always competing against some kind of other platform or the other. And so far it's one. So far it's one. But it's not because it's one just because you've done nothing. We've done a lot to preserve the web as a platform. But we need to continue to fight for it. And this talk is about that. So all of the talks that you'll see will probably focus around what things you need to do. This talk will focus on the stuff you don't need to do, stuff that you're not supposed to do. So and the point is to recognize our faults and to fix them before it's too late. So a little bit about me. First, I work as a web evangelist for Opera Software. I've been working here for about five and a half years now. I'm also a member of the W3C Mobile Web Services for Social Development Group, which gives me a little bit more of an angle on how people are actually using the web all around the world, especially in developing countries and especially on mobile, if you have any questions, you know, Twitter and my email ideas over here. So in Opera, for a long while and even technically right now I'm part of a team called Open the Web. And what this team did was a little bit unique amongst everyone else. What used to happen was if a person is using, say, Opera and he goes to a website and the website doesn't work for some reason or the other, you know, he tells us using a bug report or something else. Now there are two things which can happen. First, the site doesn't work because of some fault in the actual browser. In that case, the Q&A deals with this and hopefully in the next version of the browser, you'll fix this issue. But many times, actually the majority of the times, what used to happen was it wasn't something wrong with the browser. It was something wrong with the actual website. So what do you do then? In this case, in the Open the Web team, we actually had relationships with or have relationships with a number of different websites all around the world. The biggest ones, the smallest ones, everyone. And we talk to them and say that, OK, your code is wrong in this and this area. And this is how to fix it. Please fix it. Because that's the only way for the site to work properly. So, and I've done a lot of Open the Web work. So I have a lot of experience in how sites break. So this talk is about my experiences with it. One of the main things that I've noticed was a lot of websites broke in Opera and we knew how to fix them. It was only a matter of telling them, you know, just change this and this and this. It's just that we couldn't find anyone to talk to. Many sites just didn't have any way for us to tell them that something is wrong. So the first lesson that US web developers should probably take in keep in mind, this is not technical at all, but it's very, very important, is have an avenue where people can tell you your site has problems. Because there's so many cases in which we knew the answer, we knew how to get the site fixed. But we couldn't really tell them anything because we couldn't really get a contact in that site. So the first thing is have an avenue because if you don't know what your problem is, you can't fix it. So if you don't have an avenue where people can tell you where your site is having problems, it's going to be a bad thing. And also file browser bugs if you can find them. Browsers are just like any other pieces of technology, any other pieces of software, and every piece of software has bugs. So I would really, really like all web developers to actually file bugs, because this will actually increase the quality of every web browser out there, which will increase the health of the web ecosystem. I'll be sharing these slides later on so you can just take the links from there. True story time. So this is the story of how India's most reported site compatibility issue for Opera was solved. So what happened was people used to go to a particular site of a large financial institution in India. And out of all the sites that we got complaints from, this one was the most reported one. We got the most complaints for this one, for some reason or the other. It was very, very important, though. And we were quite confused on why is this happening. We took a look at the code, and we found that it was using a very, very old piece of JavaScript for the navigation menu, which was breaking in Opera. It was, how many people remember Dynamic Drive? It was a very old script, even from dynamic drive standards. And it detected for IE and Netscape. And for some reason, it blocked out Opera. So the only thing to do in that case was to just remove that line which blocked out Opera, and it worked. And that's all they needed to do. So I said, OK, I'll just contact them. They had a few contact addresses, email addresses, phone numbers. So I just contacted them by email, waited for a while, nothing. I'll just phone them then next. So I phoned them. And keep in mind, this was at 3 PM or something. I called them on a guy's number, a woman picked up. And she was like, sir is not over here. He's gone to lunch. I don't know when he'll come back. This is like 3 PM. It's like, how long is your lunch break? So yeah, it could be. So anyways, yeah, they were bankers, basically. So yeah, it was really, really a pain to actually get a contact over there. Finally, I found a contact who was the manager of that site. So I said, OK, this is the issue. Please fix it. It's a very, very trivial fix. He said, OK, I'll fix it. Didn't fix it. So what happened was, after a while, I knew that I had to go to Bombay, the site was actually based in Bombay. I had to go there for a conference. So I said, OK, I'll just go there. And now, since I'm going to Bombay, I'll just stop by their office. And since there's such a big financial website, organization in general, their office was pretty much like a fortress. I had to go there. I had to remove the battery at those times. I had a Mac, which you can actually remove the battery. They then said, OK, turn on the laptop after putting on the battery on. Turn on the laptop so we know that it's an actual laptop. And go through multiple layers of security. They call the guy, are you supposed to meet him or not? They gave me a cheat saying, when you come back, you have to sign it from that person. A lot of different things. I had to go six or seven layers of security to meet them. Now, finally got there. And I realized that I'm in a meeting room which doesn't have any internet. I was like, huh, OK, what do I do now? So they said, OK, and I had actually edited the source code in Opera. You can actually edit the source code in Opera and see the results right there and then. So I had actually done that just to verify that the solution I'm giving them is actually correct or not. But to get the original source code from them, I had to refresh the page and I didn't have any internet access. So I said, OK, what do we do now? So they just printed out the source code of their entire web page and gave it to me. And they also gave a pen. So now I have a pen and their source code printed out. And I have to mark on pen and paper. Like this is the line numbers. You have to change this from this and this and this. And finally, I did that and gave it to them. And it took two weeks. And then I have an email saying, we have finally fixed this issue and now we're going to test in Opera and this and that. So this is how it actually got fixed. It shouldn't be this hard. It shouldn't be this hard. Always have a process and an avenue where people can actually report where things are going wrong and why things are going wrong. Sometimes it's free QA because the people who are reporting that issue will probably give you the solution as well. So it's almost like free QA. So always have this. Always have this thing in place. We did a lot of stuff apart from this as well when it came to site compatibility, but I'll skip this for now. One thing I wanted to mention was also laziness or forgetfulness. Actually, this title is a little bit wrong because it's not about laziness or forgetfulness. One other common issue that we faced was there were many websites which use an old version of a library, like for example, an old version of jQuery. Now generally what happens is you make something and then you forget about it. You make a website or you make a web page or part of a web page. Once you're done with it, you forget about it. Maintenance is something which is not the first priority. So what used to happen was people had an old version of jQuery which had a bug which struggled opera. And in the newest version of jQuery, that bug is fixed. So it works in opera. But the site is still using the old version of jQuery. The lesson is make sure your libraries are updated. This is something that people miss. It's such an obvious thing, but people miss so much. So always, always have that. And then there are obviously bad coding techniques, like that dynamic drive script that we had. And of course, there's many other scripts like that which do a lot of browser sniffing. And there's many other different types of code which can go wrong, but I'll focus on browser sniffing. I trust everyone knows what browser sniffing is. Does anyone not know what browser sniffing is? OK. So browser sniffing is something in which you say that, OK, every browser has an identifier. So what many sites do is say, I'm only going to allow, say, Firefox and IE and no one else. So if you are on Chrome and trying to visit your website, that website, you're blocked. If you're on opera and trying to visit that website, you're blocked. A lot of times, this happens. And especially for opera, it was the case. Like a lot of times, for no fault of our own, no, we were just blocked. And this is something which is a very, very, very bad development practice. So browser sniffing sucks. Don't ever do this practice. And just to emphasize how bad this is, I'm going to run in bigger fonts. It really, really sucks. And big websites do it. It's not just small people who don't know anything. It's like big websites which sometimes do it. And it's a bad development practice to do it. Please don't do it. You know why every browser lies in the US strings? It's because they want to get around stupid browser sniffing code. Every browser lies when it comes to the US strings. Every browser. And I'll tell you a story. The case study of opera 10, we were in opera. At that time, we were the first browser to have a double-digit version number. At that time, Chrome didn't have a double-digit version number. No one else did. We were the first ones to go into double digits with their version numbers. And apparently, so many sites did browser sniffing in such a stupid way that they thought that no browser will ever possibly have a double-digit version number. No. That cannot happen. That's against the laws of physics or something. So what ended up happening was, this was our US string, by the way, opera and something like this. That's what's the alpha, opera 10 alpha. What we found with the alpha was, some major sites detected opera 10 as opera 1, because they only considered the first digit. And since it was opera 1 or something, they said, OK, it's a very, very old version. Let's give them the, let's block them or give them the error message or something like that. And for no fault of our own, we were just blocked out of so many websites. And there were some major websites, like, for example, Bank of America did the same thing. It's a Bank of America. It's like a really, really big deal. And it's blocked. So please don't do browsers sniffing. You never know how technology will change. You never know which browsers might come up in the future. So we made the US string, say, opera 9.8.0. Until this day, it says opera 9.8.0. Simply to get around that kind of stuff. Later on in the US string, we say version 10 or version 12 or whatever. But in the beginning, we say opera 9.8.0. Simply to get around this. And if you think we lie in the browser sniffing thing, take a look at the Chrome US string. It basically, if the Chrome's US string was Pinocchio, their nose would be from here to the moon. They lie about everything. They say, if someone says, if a site comes to the Chrome US string and says, OK, are you Mozilla, I guess. Are you Apple? Are you Safari? Of course. So they say that they're everything. And I don't blame them one bit. They do it because there's so many sites which are blocking some thing or the other based on the US string. Just don't do it. It's a bad practice. It's not scalable. It's not maintainable. And it's just going to cause you pain in the end and everyone else. To this day, there's a major global shopping site that you all know about, but I won't name, which browsers and gives Opera quality code. There's navigation over there, navigation menu, which doesn't pop up in Opera. We have passed it from our own side in Opera. We have a system in place called Browser.js, in which we can actually remotely do patches for websites. So most like 99% of Opera users who have enabled Browser.js will not notice this. But the very few who have Browser.js and disabled, if they go to that website, they'll find that navigation menu is not popping up. But if they spoof their US string to say that they're Firefox and load the same website in Opera once again, the navigation menu will pop up. So these are the kind of things which happen on major websites sometimes. And we actually tried to talk to those guys in that huge organization, that website. And what we found was, and this is just hearsay, this is just rumors because no one really confirms these things. But what they said was, this piece of code which did the browser sniffing was, it's a really, really old piece of code. And now the people who made this have moved on. And no other team is willing to take responsibility to get this code and fix it. So now we're stuck. So this sometimes happens. So that's why I'm saying browser sniffing really, really, really sucks. If you want to do browser sniffing, do it really very rarely, like the last option. Only do it to address a bug. Only target a particular version of a particular browser, so that in the next version if the browser fixes that bug, he's allowed in. So only do it in those cases and always offer a fall back if possible. Do feature detection, I trust most people know what feature detection is. It's basically about saying that our capability detection is sometimes also called. It says that my website requires this and this standard support. I don't care what browser you have. If your browser supports these and these standards, come in, you're welcome. So this should be the real thing. I'll skip over these. Yes, modernizing is a great way to do feature detection if you're cool with libraries. But yeah, one more thing. Use libraries very, very sparingly. The reason I'm saying this is because your users are literally paying for libraries, like literally. I mean, you are paying for the extra bandwidth that libraries occupy, but your users are as well, especially on mobiles. How many people over here have a GPRS plan or a data plan on mobile? How many people have an unlimited plan or a few? So that's what I'm saying. Everyone else is paying per KB, and it's extremely expensive. So every time you have a library with unnecessarily large file size, you're literally asking your users to pay for it every time. And one more thing regarding libraries. I love Bootstrap, by the way. I'm not saying it's bad. But I've seen a recent trend, and a few others have seen a recent trend in which all the sites using Bootstrap are looking exactly the same. So put some effort into at least making it look a little bit different. A person who looks at that shouldn't be saying that, OK, it's just a Bootstrap site. It's done nothing else. Otherwise, it'll just look the same. Everything will look the same, and it just sucks, really. Also, this is a very, very important point. Rethink your native app. Rethink your native app. This is from XKCD. I want to visit an incomplete version of your website, where you can't do download our app. No? OK? Or no, but ask me again every time. And I recently came across this blog post. I'm not an iOS, so I can't really verify this. If someone is on iOS, please verify this. About Korad, there's this guy who went to the Korad website on the mobile website, and what he found was it says, read the app to read all the answers. You only support reading answers past the first one in our iPhone app. It's correct, right? And if you do, exactly. And if you view the source code, it has all the answers. They're artificially blocking all the answers so that you go ahead and download the app. I mean, this is very intentionally hurting the web platform. This is something which really, really, really sucks. If someone from your team or your manager suggests this, then I would suggest slapping them in the face. And if you're not that violent kind of a person, then just kick them in the balls. That's even worse. And if your site is a blog, don't make a freaking app for it. See, so many sites, which are pretty much just blogs, and they make apps for it. And people might even download those things. But nowadays, we have so many apps. And app fatigue is a thing now. People download apps and then don't use it forever. It's a better, if you are a blog, it's a better strategy to just ask people to bookmark your site. Just do that. Don't waste time on native apps and whatever. It's ineffective. And also, stay up to date on the latest web techniques, latest in web technology and web techniques. You don't need to use everything in your next project. But I'm betting that if you're aware of everything, then you might find something useful for your next project. I've seen so many people, especially in the government, where I talk to people who make these horrible websites. And I talk to them. And when I was meeting them, I was like, OK, there must be something evil in them. They must have some plan for global domination of shady sites. And as I was talking to them, I realized they were pretty nice people. They were run of the mill just like me. It's just that they weren't curious enough. And they were just doing stuff they were told. And they didn't really care about anything else in the web domain. They were just doing what they were told. That's it. Don't be that guy. Learn about everything else as well. What's going on in your next three? And there are easy ways to do this. The easiest way would be to download the latest nightly of different browsers and follow the development blogs of these browsers. Because every time you browse this, release snapshots or nightlies, you have a small blog post generally that says, OK, in this new snapshot or in this new nightly, we have this and this and this. There are two or three new things, and you can just go ahead and learn about them. It's a very easy technique to just keep up. And also, read up, like illicitpower.net. I mean, these things are obvious. Recently, we announced our switch to WebKit. Are people aware of this? OK, one interesting thing about this is this building. This building is probably the most important building in rendering engine history, I would say. Because two of the major rendering engines had their origin over here. This was of a software's old office, 98 Waldemar Transcata. And just two floors below, there was the office of Trolltech. Trolltech used to make something called KHTML, which later on turned out to be with Apple WebKit. So this building actually has the distinction of having two web browsers originate from it, two web engines originate from it. And there have been a lot of reactions all across the web, some positive, some negative, some introspective, some optimistic. But amongst all of these reactions, there are a few small things to remember. One is this change is gradual. This change is in sudden. So if you're using Oprefixes, I hope you are. There are very, very few Oprefixes as it is. So if you are using them, keep using them. Don't stop, because there's a few products like Opera Desktop, Opera Mobile, which might come in with WebKit a little bit sooner. And Opera Mini, for example, might come in a bit later. The timelines are not decided yet. So keep using the Oprefixes, because Presto is not going just like this. It's going to be a gradual phase up. And also, cheer and be happy if you are. But don't be happy for the wrong reasons. I see so many people who are saying that I'm happy I don't want to test one more browser anymore. But you should be testing on everything available. And especially, this is important for mobile, because on mobile, with Opera Mobile eventually going to WebKit, it's going to be almost a WebKit domination. So people will be very tempted to just test on WebKit when it comes to mobile. And I would say, this is the wrong approach, test on WebKit definitely, but also test on other rendering engines. Still, even if they have a very, very low market share, we know it hurts. So please, please test on other rendering engines as well, not just on WebKit. And test on other browsers. If you're doing presentations, this is especially important for people who do talks and presentations. I see so many people doing talks and presentations when they're doing explanations of CSS. They always have WebKit and MOS. They don't have O, they don't have MS. They don't even have sometimes the actual unprefixed version as well. So always have those things, not just WebKit and MOS, the various cross-project testing services. You can find them on their own. One thing about Web Accessibility, don't ignore it. We've already had some really, really amazing talks on Web Accessibility. I did one talk on accessibility and Aria in 2010 in Meta Refresh. Don't ignore it. You don't know how it will affect other people. Somebody's only access to the outside world depends on it. I remember there was this one time, I think two years ago, where I was attending this conference in Barrier Break. And they had all these people who were actually disabled come over there, and they were handing over the mic to each and every one of them, saying, and the question was, what does the web mean to you? There's this one guy who had, I think, muscular dystrophy. He couldn't really move anything below his neck, except for a few of his fingers. He used the internet using a trackpad and using his fingers. And when the mic came to him, I clearly, I mean, I remember it so clearly. His eyes welled up, and his voice choked. And he said, the internet is the only access I have to the outside world. And if we make websites which do not cater to people like him, he'll be shut out of the internet. Now, no website, if you imagine no website was accessible, what kind of experience he will have, what kind of life he will have, that guy can not go outside his room for most of the year. He's confined to a bed. So keep in mind that the web means a lot to you, but it might mean the world to someone else. One more general observation that I had is that there are a lot of parallels between web accessibility and mobile web best development practices. So if you know either of the two, it's very easy to know the other thing. And there's a document which actually lists some of these similarities. Another observation that I made was web accessibility is not something which is difficult to learn. It's actually pretty easy to learn. It's just you need to give a shit. You need to give a shit about other people. You need to give a shit about something other than your job or your role or what your manager says or something like that. You need to care about the web. And one more personal observation that I had with regards to web accessibility was if you're talking to a person and he really understands and really cares about accessibility, the chances are he's actually a very good front-end developer in other respects as well. If he doesn't care about accessibility, he may still be good in other areas. But the chances of him being actually really, really good if he cares about accessibility is higher. So if you're in an interview and you find someone who is actually a front-end developer who really cares about accessibility, I think you found a good guy. So how to defend the web? Any time you go and you see, I'll recommend this practice actually. Before you start a project and before you release a project, just go to the street and see these people on the street. And imagine what kind of devices they have. Imagine what kind of browsers they have. Imagine what kind of connections they have. And if your site or a web application requires them to change their browser, requires them to change their connection speed, requires them to change their OS, requires them to change their device, just for them to view your website, then there's something wrong probably. So have this exercise. So how to defend the web? Keep in mind we're not all the same. Everyone is different. Now we're all in this together. Let's not leave anyone behind, whether it's a person with a different browser, whether it's a person with a different ability or disability. Let's not block anyone. Because we see it so many times and it sucks. And if there's one thing that you might take away from this, is that speak up. I've seen so many people who are really, really nice. But in their organizations, something bad is happening. And they say, oh yeah, I totally agree with you. But other people don't agree with me and nothing happens. I said, did you speak up? Did you raise your concerns? And they are silent. So if there's one thing that you should take away from this talk, is to speak up. Be that guy who speaks up for the web. I just feel that if there were more people just speaking up against, say, browser sniffing or accessibility or something like that, if there are just more people speaking up within their organizations, we'll have a much better web. We'll have a much more accessible web. We'll have a much more efficient web. We won't have a web which blocks their own website just for that native browser download. So be that guy who speaks up, because we really need you. The web really needs you. And be that guy who speaks up. Cheers. Do we have time for? Hi. Is Opera moving to WebKit? What will happen with Dragonfly? What happened to? Dragonfly. Dragonfly. Right now we're still evaluating. But yeah, it's a very, very awkward position for me to be in, because there are certain things that I'm not allowed to say, because of NDAs and stuff like that. So the only thing I can say at this point is we're still looking into how to merge things. Hi. It's a question regarding accessibility, since it's one of your passions, I assume. Carrying forward from what the earliest people was talking about, you said you had interactions with the government on several platforms to actually improve the government or a public utility sites. What is Opera done in this regard? Because if you look at the accessibility point of view, none of the sites starting from even the railway site is accessible. So if you're looking at any screen readers trying to access this, this is one. Secondly, does Opera back screen readers in itself on multiple devices? Or do you have some recommendations for this? When it comes to accessibility, we've been in developer relations and in our department fighting internally for more stuff to be done on accessibility. Fortunately, with this move, finally, we'll have a much more accessible opera. So with this move, you'll find that it works out of the box. When it comes to interaction with the government, I would say that it's not that I have really, really unlifted access to them. I've conducted workshops with them. I've talked to them on a few occasions. I have a few contacts inside. And at the same time, it's not that I have any say or I have any influence in the government itself. But I have talked to a few people inside the government and raised the issue of accessibility. And I'm not the only one, by the way. I'm not even the major one. There's a lot of good work done by Barrier Break, for example. They've been doing a lot of stuff on sending feedback on the new laws for electronics as well. You probably are aware of this. So in this field, in terms of accessibility, there's a lot of stuff being done not just by me, but by all the players as well. Sorry, the second part of it? Is there any screen reader or do you recommend any accessibility tools from your end? Accessibility tools in terms of screen readers, which work in Opera or screen readers in general? Yeah, Opera first and then general. In Opera, in Mac, you can use the default screen reader that they have. Anything else right now we're having problems with it because of one particular API. Apart from that, there are a few tools like I made a tool, which is a little bit like the web developer tool that you have in Firefox, in which you can actually do a wave, a check of the website that you have. So I'll talk to you later on on the URL for this. And it'll also do stuff like analyze basic issues, like if images don't have proper alt text and stuff like that, it'll highlight that. When I talked to my fellow developers about accessibility and I gave the links of WCAG 2.0 or W3C website, they find it very technical and very long. Would you recommend any very easy to understand article guidelines for anyone can understand? Well, there are plenty of tutorials. I don't have any specific one, but there are plenty of tutorials on the net, which explain the WCAG guidelines in a 2.0 guidelines in a normal way. And many talks as well. I can get back to you on this, but I don't, on the top of my head, don't have a URL or a site which does this, but I'm sure we can find out more. And if you don't, then we can make something on our own. Maybe that's a project we can do. Yeah, the W3C site, I mean, he said that he looked at the guidelines. You can tell him. So there's a separate wiki in which things are explained in a better way. And also there's work going on on the web platform, webflatform.org. And we are actually wanting more contributors to explain stuff like this in a normal and easy way. So we would like contributors to actually do this on webplatform.org. If you are willing to do this. Sorry. The background thing, I work with the accessibility group. I have an organization for the blind. So I've got a slightly extremist view. We as developers, I also have a development community. We as developers listen to the great talks, take out the best, and then we don't implement because like my fellow developers saying it's tough to implement. So just an extremist view. If you as opera or any browser, for that matter, was to take a stand that if your website or your application is not user friendly, which is accessible to all, you will not showcase it or you will not preview it. Will that be a stand that opera would back so that you know every developer out there will make sure that every website that is published is accessible? Will that be a stand that you'll back? You're making sure that all the sites they are done by the developer for the world is making sure that it is accessible by all. Can I answer or someone else want to answer? You want to answer? Okay. Then I'll give my answer as well. Yeah, sure. So essentially, you know, I don't think really we should do that because at the end of it, it would take a migration phase basically, you know? A lot of people will have to go through a learning curve and essentially a lot of websites will change over time, but that'll happen over a period of time. And at the end of the day, the loser will be the users. So, you know, depriving a lot of people of the web for a long time is not worth it. Yeah, I mean, can I answer this now? I will answer this. I was just saying that, you know, you can't try to make things accessible, more accessible by making them less accessible. If you block it for everyone else, then essentially you're making that website even less accessible. My theory there was you've already gone ahead and developed a 99.9% of your websites which are non-accessible. You've already gone ahead and developed it. So just realizing it at a forum and not taking the cues from it and going back to the old age is not the answer to this. So what I'm trying to say is if an opera or if a standard like a browser was to decline accessibility, won't that make it mandatory for that that developer community at least to come up with sites which are smart? Okay, so let me just answer it now. We've done something like this in the past, believe it or not. This was not for accessibility, it was for something else. How many people remember XSTML2? Or XSTML, sorry, not XSTML2, right? Now, how many people know that for a site to be, you know, rendered as XSTML, it needs to be rendered with a certain MIME type, MIME type, a few people, right? And what used to happen was people used to make, you know, XSTML sites and they used to validate it in the browser and it said that, okay, it's valid and they used to just display it, right? But it didn't used to be in a proper MIME type. The ones which were in a proper MIME type were supposed to be interpreted as an XML document, right? In every other browser, when this happened and there was an error, you were supposed to block the webpage and have an error message, right? If it was proper XSTML, served with a proper MIME type, MIME type, and there was an error in the page, you had to display an error message. You were not supposed to display a webpage, right? We were the only one still, I think, a year ago which did this. Every other browser said, fuck that, right? And we suffered. Everyone else was saying, why is my site, you know, displaying properly in every other browser and in Opera, it's not. We paid for this. We already tried this and we suffered for this. Ultimately, we said, you know, it doesn't really matter and then we said that, okay, everyone else, we'll just, you know, do things like everyone else. So we've tried this in the past and the answer is that it's just ineffective. That's the main thing, that's why we won't do it, yeah? Just one more quote I would like to add, you know, this is about education. There was a long blog post I read. It said, learning is a result of inspiration, not perspiration. So I just remembered it, you know, we can't perspire these people and force them to learn. They have to be inspired and that's what's happening here, you know, in these forums, we are inspiring people to learn. Yes. Can I add something? Imagine the business impact which gets created by people not being able to access normal sites on a real basis and how many businesses suffering from it. So I think education is the key way to go and not forcing it. Amazon Webster will go down, your site bookings for online ticketing, ClareDrep was down. So think about that. I mean, it's a combination of two things. I agree in the fact that there's some amount of force required, but I don't think this, the force required should be on the side of the browser. It should be on the basis of legislation. I'm just talking about things which are effective, right? And the things that are effective are one, education and two, legislation, right? No amount of education would have, in my opinion, would have worked so much as, you know, all the disability acts around the world have. So, you know, education and legislation, these are the two things which will work. Anything else probably will not have that much of an impact. It won't be as effective. Okay. I'm, mine's also probably an extremist view, but not that I would act on it. I guess we are all hypocritical as citizens, as developers or any other thing. We are insensitive to a lot of things that happen within our own country, be it northeast or be it impoverished children who are malnourished or any of those things. And all the empathizing that happens with the disabled are all, most of the time, it's a luxury which we do after our bellies are filled. And I don't see anything happening. And we won't feel what it is to be not having access, however much we want to empathize or sympathize. And we'll, as long as our daily bread is taken care, we'll just go on, go on hacking and doing whatever cool stuff we like to do in coding. But I don't think we'll make a difference to the world. And I don't think it'll change because we have been like this for centuries. So, just being a geek won't change. I'm just, just, okay. The point is not to have a realistic experience of having a disability, right? The point of empathy is to understand not in a very, very like a virtual reality kind of way, okay, I have like kind of like this. It's not like that. Empathizing is just about trying to put yourself in their shoes for a while and try to see what kind of problems they might have. And then just being a little bit sensitive towards them and making, and keeping them in mind whenever you're making new stuff. That's all we're saying, right? And of course, there are many people who will not care about this. And that's why I'm having this talk because it's very, very important when you go back to your teams and you talk with your managers that you say something, at least. Just raise that point. Maybe you'll be able to convince your managers or your team leaders to do something which is good for the web. Not just accessibility, it's just one small part. There are many other things which go into the health of the web that I talked about that you should probably keep in mind, you know? Yeah. I was just gonna add, if it'd be really nice if I think we had something on accessibility on the lines of actually showing how hard it is for people to use these sites. We have very small stuff but I don't think we have seen anything that realistically showcases how hard it really is. So I think someone could do that sometime today or something would be really nice. Yeah. If you guys have iPhones, you would know this. If you can go and switch on your assistive technology and then you try using it without looking at the screen. It's actually really good and it shows you the kind of detail that Apple has gone into to make sure that their phones are accessible to everybody. But yeah, just put it back. I think I don't want to spend too much time on this because we should break for the next thing. But I feel your pain because I've done a lot of work around this area. I've worked a lot with disability and internet access. There are efforts in Bangalore. I think that proactive blocking is definitely not the answer. I'm with Navjot Shwetank on that. I think though that interests can be aligned in different ways. For instance, one thing that I used to say when I did an accessibility talk was that Google is the world's biggest blind user. Google can't access images. Google can't understand data which is not textually represented and which is not well marked up. So you need to make arguments for developers or business owners which makes sense to them. Doing so will help our case far more. And we need to remain hopeful and keep working on this. We can't give up hope and act reactively. We have to be proactive about this. More questions or should we cut? I think we'll break now. Thanks Shwetank. And I wanted to thank Opera for bringing you here and having you with us.