Podcasts about wai aria

In this episode, Karl Meisterheim and Taylor Page engage with Scott Vinkle, an accessibility specialist at Shopify, to explore the importance of accessibility in web development. They discuss Scott's journey into the field, the challenges developers face when implementing accessibility, and the continuous nature of accessibility efforts. The conversation also covers legal aspects, practical tips for developers, and strategies for educating clients about the benefits of accessibility. Scott emphasizes that accessibility is not just a checkbox but an integral part of creating quality products that cater to all users. Takeaways Accessibility is an ongoing journey for developers. Understanding user experience is crucial for implementing accessibility. Accessibility should be embedded in the workflow, not treated as an afterthought. Legal compliance is important, but the focus should be on user needs. Small changes can have a significant impact on accessibility. Testing with real users is essential for effective accessibility. Accessibility tools are often built into modern operating systems. Educating clients about the business benefits of accessibility is key. An accessibility statement can help manage user expectations. Continuous learning and adaptation are necessary in the field of accessibility. Timestamps 00:00 Understanding Accessibility in Development 01:38 Scott's Background and Role at Shopify 04:35 The Importance of Accessibility 07:32 Accessibility as a Continuous Process 10:24 Overcoming Barriers to Accessibility 13:39 Personal Experiences with Accessibility 16:36 Conclusion and Final Thoughts 17:25 Legal Ramifications of Accessibility 17:53 Understanding Accessibility Standards 21:40 The Challenge of 100% Compliance 24:41 Prioritizing Accessibility Improvements 27:40 Tools for Accessibility Testing 29:57 Practical Steps for Accessibility Implementation 32:34 ARIA: When and How to Use It 39:30 Low Effort, High Impact Accessibility Changes 42:39 The Business Case for Accessibility 48:08 Risk Management in Accessibility 51:51 Tools and Strategies for Accessibility Compliance 56:22 Creating an Accessibility Statement 58:18 Final Thoughts and Reflections Find Scott Online https://scottvinkle.me/ Resources Scott's Article on Accessibility Changes: https://www.shopify.com/partners/blog/3-product-detail-page-accessibility-issues-to-fix-right-now Fable Accessible services: https://makeitfable.com/ ARIA authoring practices guide: https://www.w3.org/WAI/ARIA/apg/ General help docs on customizing your theme and accessibility: https://help.shopify.com/en/manual/online-store/themes/customizing-themes/accessibility Dev Changelog Increased limits for automatic function-based discounts: https://shopify.dev/changelog/increased-limits-for-automatic-function-based-discountsNew dynamic source attributes available in the online store editor: https://shopify.dev/changelog/new-dynamic-source-attributes-available-in-the-online-store-editorBuilt for Shopify category-specific criteria are now available: https://shopify.dev/changelog/built-for-shopify-category-specific-criteria-are-now-availableConditionally disable gift cards in checkout using custom logic with the Payment Customization API: https://shopify.dev/changelog/conditionally-disable-gift-cards-in-checkout-using-custom-logic-with-the-payment-customization-api Signup for Liquid Weekly Don't miss out on expert insights and tips—subscribe to Liquid Weekly for more content like this. https://liquidweekly.com/

Aurooba and Brian dig into the semantics of not only what makes an accordion accessible, but also why a11y should be a first class consideration when you build anything on the web. They also explore how different ARIA tags work and what they indicate, taking a previously inaccessible accordion and transforming it into something navigable visually, with a keyboard, and with other assistive devices. Along the way, they also think out loud about the definition of an accordion and what that really means.A full transcript of the episode is available on the website. Watch the video podcast on YouTube and subscribe to our channel and newsletter to hear about episodes (and more) first!Source code for this episode – https://github.com/viewSourcePodcast/viewSource-blocks/tree/add/accordion-block-a11yCoding inclusive collapsible sections – https://inclusive-components.design/collapsible-sections/ARIA Guide to Accordions – https://www.w3.org/WAI/ARIA/apg/patterns/accordion/Exploring what a React component is : https://youtu.be/eCKyI12JJswUsing React on the WordPress frontend : https://youtu.be/TtmY2Ck_6i0Brian's website – https://www.briancoords.comAurooba's website – https://aurooba.com (00:00) - Introduction (00:15) - The importance of accessibility (03:25) - The different considerations of making something accessible (05:35) - Recapping where are are in the Accordion Block series (06:50) - Demo-ing an accessible accordion (08:36) - Defining an accordion (10:40) - Header versus heading (12:21) - Keyboard accessibility (15:32) - What does ARIA stand for? (16:03) - Coding an accessible accordion (16:43) - The components of an accordion section (17:23) - Diving into the semantics of an accordion section header (23:11) - Targetting ARIA tags in your CSS (24:21) - Digging into the accordion section panel (26:32) - Animating an accordion (27:46) - Next Steps (29:34) - Conclusion

今回は、Web関連の仕様書の翻訳を手がけるもんどさんをゲストにお迎えして、使用翻訳を始められた経緯やアクセシビリティー関連の活動などについて伺っています。また、11月11日に開催されたJapan Accessibility Conference Vol.1についても話しています。 写真：ゲストのもんどさんが「Japan Accessibility Conference vol.1」で登壇したときの会場風景です。遠くにいてるのがもんどさんです。実在していました。 オープニング・トーク 今回のizuizuからのお題は「商店街」です。 もんどさんを交えて CSS 2.1仕様書の日本語訳を手始めにWeb関連の仕様書の翻訳を手がけるようになられたというもんどさんに、まず翻訳に取り組むようになった経緯を伺っています。また、その後取り組まれたWAI-ARIA 1.0の翻訳やウェブアクセシビリティ基盤委員会での活動についてもお話しいただいています。 続いて、先日開催されたJapan Accessibility Conference (JAC) Vol.1で担当されたセッションなどについてご紹介いただいています。 そしてAccSellの3人も関わったこのイベントについて、それぞれ感想などを話しています。 今回のゲスト もんどさん アマチュアウェブ仕様翻訳者 WAI-ARIA 1.0、HTML 5.0 (web developer's part)、CSS 2.1などといったウェブ仕様の翻訳を公開している中の人。ウェブアクセシビリティ基盤委員会（WAIC）の翻訳部会で作業協力者としても活動している。 Twitter : https://twitter.com/momdo_ 収録後記 研究者が技術仕様を参照する場合、英語で読むのが一番早く確実なので当然のようにそうするものですが、Web関連の仕様書を参照するのは、おそらく研究者よりもそうでない人の方が圧倒的に多いと思います。そうすると英語が苦手という人も少なからずいるわけで、翻訳版が非常に重要です。特にアクセシビリティーのように、その考え方などをなるべく多くの人に伝える必要がある分やの文書については、翻訳版の存在が不可欠です。ただこの翻訳という作業、継続的にやるのは結構大変だということを経験的に知っているので、今回もんどさんのおお話を伺って頭が下がる思いでした。 (中根 雅文） Twitterの中にしかいないと思っていたもんどさんとお話できることになるなんて・・・。これからもお世話になります！（仕様書の日本語） (山本 和泉） 同じ翻訳でも、仕様書の翻訳ほど骨が折れて、しかも公開した後の影響力が大きいものはないと思います。私自身も、もんどさんの日本語訳にどれだけ助けられてきたことか。ウェブアクセシビリティ基盤委員会の作業部会でSkype越しにお声だけは何度もお聞きしていたものの、今回のようなお話を聞ける機会がなかったので、先日のJapan Accessibility Conferenceでの打ち上げでお話できたことと合わせて、もんどさんのことをより深く（？）知ることができてよかったです！ (植木 真）

Descripcion del programa Juanjo Montiel es desarrollador .net, experto en accesibilidad y participa activamente en la fundación techdencias, donde cacharrea y divulga conocimiento tecnológico. Nos hará de guía a través de ejemplos para mostrando los problemas a los que se tiene que enfrentar a diario lidiando con productos no accesibles, y lo sencillo que puede llegar a ser resolverlos. ¡Esperamos que os guste el episodio y como siempre nos vemos al final! ¿Queréis participar? ¿Queréis participar y ayudarnos a decidir que grabar en WeCodeSign y proponer invitad@s? Aquí podéis participar Preguntas rápidas: Juanjo Quién me ha inspirado: La gente que comparte conocimiento Recomiéndanos un recurso: Blog de Olga Carreras Recomiéndanos a un invitado o invitada: Coces de grandes empresas que podría cambiar las cosas ¿Qué tema te gustaría que tratásemos?: Aprender CSS sin pantalla Contacta con: Juanjo Twitter de Juanjo Web de Juanjo Programad.me Links del programa Ejemplos de Juanjo sobre accesibilidad WAI-ARIA Contrast Ratio by Lea Verou WebAIM Color Checker Recomendaciones de Ignacio a11y Project Using ARIA Principles of Accessible Design Charla de Juanjo en el FrontFest Patrocinadores Fictizia.com Contacta con Ignacio Web de WeCodeSign Twitter de WeCodeSign eMail de WeCodeSign Web de Ignacio Villanueva Twitter de Ignacio Villanueva

マークアップエンジニアの小枝 繁子 / みるく（@milk54）さんと、web アクセシビリティに取り組んでもらうためのアイデアや実践していることを教えてもらいました。小枝さんが実行委員のひとりとして携わっているイベント「D2Draft」で実際やっている取り組みを紹介しながら、web アクセシビリティを学ぶことの面白さと難しさについて意見交換しました。White StageD2DraftD2Draft イベント情報D2D アクセシビリティ勉強会 ～WAI-ARIAでアクセシブルにしてみよう～を開催しました。アクセシビリティの祭典マウスは使うな！属性は同じだとしても人それぞれ明確が答えがないから議論するWAI-ARIAの正しい使い方 〜あるある？ケーススタディ〜寛容的なマークアップ言語であるが故の難しさアクセシビリティのチェックができる人が必要澤田望さんとのポッドキャストWCAG 2.0 達成方法集NVDA 日本語版ガイドブック顔も知らない誰かの笑顔のために

Marcy Sutton: @marcysutton | marcysutton.com | Deque Systems Show Notes: 01:07 - Deque Systems 01:54 - Accessibility Tool Integration and Testing 05:26 - Configuration and Success Criteria 07:04 - What is accessibility? WCAG 09:22 - Spurring Adoption of Accessibility 12:09 - The Accessibility Matrix 16:56 - Accessibility-First Development 18:12 - WCAG and ARIA Roles 24:57 - Test Automation vs Human Interaction 28:56 - Empathy Building 30:45 - Porting to the Web 35:57 - Accessibility in Single-page Apps and Focus Management Resources: axe-core aXe aXe Developer Tools WCAG (Web Content Accessibility Guidelines) Web Accessibility for Designers WAI-ARIA Authoring Practices 1.1 First rule of ARIA use Access Works: Usability and Accessibility Training Marcy Sutton: Notes On Client-Rendered Accessibility a11y on Slack Transcript: CHARLES: Hello everybody. Welcome to The Frontside Podcast Episode 61. My name is Charles Lowell. I'm a developer here at The Frontside. With me also is Mr Robert De Luca, a developer at The Frontside and today we have with us, Marcy Sutton who is going to be talking with us a little bit about accessibility, both in the large and the small. Welcome, Marcy. MARCY: Good morning, everyone. Happy to be here. CHARLES: I know, I understand you're actually calling us from the parking lot of a ski area. MARCY: I am at the legendary Mount Baker ski area outside of Bellingham, Washington where we have the winter that is just going on and on and on and getting after it on the last few days of my birthday vacation. ROBERT: Oh, wait. Happy birthday. CHARLES: Yeah, happy birthday. ROBERT: Happy belated or happy birthday. MARCY: Yeah, it was Sunday so still on that shiny birthday week. CHARLES: Well, thank you for getting with us on your vacation and on your birthday but doing a little bit of work, you actually work at Deque Labs. What is it that you guys do over there and what's your particular area of interest and work there? MARCY: Deque is an accessibility company. We have people who work on products and services for accessibility. We help people avoid lawsuits and make their websites and mobile apps more accessible to people with disabilities. My slice of that work is on the product team, where I work on browser extensions, APIs for developers. Basically to make it so you don't have to write every single accessibility tool or test yourself. You can pull in these APIs and get some of that experience that Deque has built up for years and years and years, which was part of the reason I went to work there was to learn from them. We make tools that make it easy for you to make use of that knowledge in your applications. ROBERT: That's awesome. It's like a base JavaScript library that can be ported anywhere, like to browser extensions. I know we use it in Ember accessibility testing. That's really cool. That's where I've gone for the way I write JavaScript. It's in a base library so everybody can use it and it's even more awesome that it's testing and like wrapping tooling around accessibility because I know a lot of developer-minded people want to see like a failed built. CHARLES: Yes, what does that experience look like? I mean, coming from someone who's never even heard of these tools, how would I integrate them into my project and what would change about my workflow? What information would it surface? MARCY: The best place and the reason I work on these products is that I saw projects go out the door broken a lot of times, when working in agencies or maybe testing isn't part of your methodology. Personally in my career, I just knew there had to be a better way. I got into software testing and the more I learned about it, the more I thought that it was sustainable, you could pull in other APIs to help you write better tests. I went to work on axe-core, which is the JavaScript library that we've talked about a second ago. That really is bottling up all of these accessibility tests that you can automate some of the accessibility checks for things like if your HTML markup is in a good state and you're using attributes correctly. Basically, saving you from having to write all of those little microtests, some of which can be sort of complicated. It's all about getting test coverage for the automated things that we can actually test for. CHARLES: You described a pretty wide-ranging coverage. How do you go about actually implementing that into your CI process? Do you just install the axe-core? Do you have to load up your browser and then pointed it out? What does that look like? MARCY: Ideally, you would already have a test suite and you could just pull in the test harness. There's all different versions of aXe. There's versions in JavaScript and in Node. The core thing that you need to test is get your app running in a browser, whether it's a headless browser or could be a mounted browser but we need those actual DOM browser APIs to check things like color contrast. We need to be sort of coupled to the DOMs so that we can run our full set of tests, which is a distinction from, say some shallow rendering that you might be doing in React testing or something like that. For accessibility tests, we need an actual DOM so you could get axe-core on npm and then pull it into your project and then you basically either require or import it, depending on what your stack looks like in JavaScript. Then you have access to all of these tests. It's pretty useful since our ecosystem has evolved to cover things like npm. I've found that it works pretty well. ROBERT: That is pretty neat. You require it into your test and then you visit a page that's fully rendered and then you do aXe check, like you call a method that runs all these checks? MARCY: Exactly. You would call axe.run and then you configure it to run, either specific tests or just one test. One of the tricks that has been helpful to know is that if you disable the color contrast rule, you don't need quite as many of the DOM APIs so it will run faster in things like JSDOM, which doesn't implement the entire browser APIs. But you could call axe.run, either in your unit tests or more likely it would be in your integration tests because you'd already have a browser instance, either through Selenium-WebDriver or karma-chrome-launcher or something like that. Then you basically call axe.run, passing a callback function and then it will return to you at set of JSON results and then you can do things with those. ROBERT: When you call run, can you pass options of what you want to check? Can you filter out things that you know might -- because I imagine like if you put this into an existing app that's been going for a while, I imagine you're going to get a bunch of fails and it might be overwhelming. Is there a way to peel a back like an onion and start working at it that way? MARCY: Yes. You can get pretty specific with our API. The GitHub for axe-core has our entire API configuration. You can get pretty specific. You can filter by tags. I imagined we're going to talk a little bit more about what WCAG is but there's a set of standards that you can break accessibility down into things that you can actually assert that they are either accessible or not. There's all different kinds of what we call success criteria. All of our rules are mapped to these actual guidelines and standards because that means that our tests are helping you solve things that are actually helpful so you could filter by the different levels. Maybe you want to configure it with custom rules. We have some additional products for that. You can get pretty specific with what you want it to run. ROBERT: It's extensible too so you can add your own stuff. MARCY: You can and we do a lot of work with some of our clients to actually help them write custom roles so that's a service that we offer. But the API is pretty configurable on the JavaScript side so you can do quite a bit of configuring on your own as well, which is cool. ROBERT: That is pretty awesome. You alluded to WCAG, I guess now we know how you can integrate a testing library into your JavaScript apps, let's take a step back a little bit and what exactly is accessibility and then you can start explaining WCAG because WCAG is a very big document that tells you how to go and be accessible. CHARLES: I assume WCAG is some acronym? MARCY: It is. Peeling that back a little bit to what is accessibility. I'm more on the digital side. There is physical accessibility as well for spaces. But when we're talking about digital accessibility, we're talking about making apps and websites that work for people with a broad range of abilities. Say, you had color blindness or a low vision or you're fully blind, you would need to be able to zoom in, you need high-contrast colors, you might use a screen reader if you're blind. But then there's other categories. People might actually fall into more than one category including motor disabilities, where maybe you can't use a mouse and you have to use a keyboard only or a keyboard with one button, which is how we think about a switch control --that's another device. You might be deaf or hard of hearing and need transcripts or close captions so any audio or video content needs an alternative of some kind. Then there's cognitive disabilities where people have learning disabilities. Maybe the language used on a website is too vague or too marketing copy speak and we need to simplify, people with traumatic brain injury like Stephen Hawking has ALS. I discovered at some point in my career that I could actually make the web a better place by supporting all different kinds of people. That's really what it's about for me is doing good craftsmanship and making sure that you're actually making things as accessible as you can. The WCAG thing that we mentioned, it stands for Web Content Accessibility Guidelines. It's just that. It's a set of guidelines, sort of a map to help you get there. You have to actually interpret those guidelines and put in the work to do it. The guideline is just a guideline but it gives us a really good roadmap of how to implement all of these different areas of accessibility. CHARLES: I actually had a question and this is a little bit harkening back to the discussion about the axe-core but also kind of straddling. How do you spur adoption, both the technology and the value inside of your development team? You know, we definitely make our web apps as accessible as we can because we have Rob on the team. But for teams that don't have Rob, how do you spurred option? How do you pitch it to your team and to your management structure? Like testing. Testing used to be controversial. I think in some pockets, it still is but it was something that you had to pitch or agile methodologies was something that you had to pitch. Now it's kind of accepted. It's a core-value of development, I think. I hope. MARCY: Definitely more so. I agree. CHARLES: Do you see a future where making applications accessible is just a tenet of development in the modern era and how do we get to that point? How do we pitch our teams to adopt that value? MARCY: Part of what I'm trying to do is meet developers where they're at and make tools that make it really easy and free to integrate things so it doesn't cost you anything to npm install a library and pull it in your project or to use a free browser extension. What we're trying to do is really help developers get there by lowering the barriers, just kind of a funny way to put it because that's what we're doing with accessibility is removing barriers for people that get access to things. I'm pretty optimistic about it. We talked a lot in the accessibility world about education is really needed because often, it's just that people don't know about it. I've made it my mission to spread the word as much as possible by doing talks and blog posts and just trying to get as many people on board as possible, instead of making them feel bad about it like, "Oh, you don't know about this? You're terrible." ROBERT: Oh man, you're speaking to me. MARCY: "-- You can do this." I try to bring people along and make them feel welcome because it's not really a fun experience to be like, "Oh you're bad because you didn't do this. You don't think about this thing." That's what I try to do. ROBERT: One of my first experiences in accessibility was like somebody giving me that moral argument like, "You're ruining people's lives. They can't do things on their computer." I just remember the response I had and it wasn't that, "Oh, you're right. I should go make this accessible. It was more of like I had a flight or fight response. I start to justify the reasons I didn't do and that wasn't a good experience so the way you put it, like meet the developers where they're at, I love that because that's how I've been operating too. I think accessibility is just another engineering problem and it can be an engineering problem that would be fun to solve. The accessibility matrix gets really hard and hairy as you get into it like -- CHARLES: Oops! Jargon alert! What is the accessibility matrix? Does the accessibility matrix has Neo? ROBERT: The different AT combos and since my experience stems from screen readers -- MARCY: Assistive technologies? ROBERT: Yeah, assistive technologies -- I'm doing a poor job here -- Basically, you have three levels that you work with here. It's the operating system, the type of assistive technology and if we're talking about the web, it's the browser. You could have like the matrix, the beaten path is MacOS, VoiceOver and Safari. That's going to be your matrix. Then on Windows, it could be Windows JAWS and Internet Explorer or Windows NVDA, which is another screen reader on Windows. JAWS is also a screen reader. The browser for NVDA would be Firefox. Then it can just fork in any of those different combinations that you could possibly imagine that makes it hard to debug for. But that's why I think this is a cool programming problem is because we can build awesome tools to help us do this and test for it like aXe. MARCY: Yeah. I would also argue that it's almost even more of a design problem. It's part of the additional challenges that we have to get our design friends and colleagues on board as well because the more that they are thinking about it before they handed off to us, the less we're going to be caught in these situations where we have to make it work in one browser and assistive technology but then it's broken somewhere else because we're trying to use really experimental APIs or we're just trying to do things differently for the mouse versus the keyboard. I can tell you that could be really difficult. The more we're thinking about making things straightforward and intuitive from the design side, not to say the easier job is going to be but the more successful, I think we can be as a team because it's more than just developments responsibility. There's good resources for designers as well, like a web accessibility for designers. If you just Google that, there's a great checklist from WebAIM. I think it's helpful to make it inclusive to people that we work with, not just in the development side because we really want them to set us up for success or else were really just fixing problems that not at their core. You know what I mean? ROBERT: Yeah, as they come down the pipe, we're kind of dealing with them instead of getting ahead of it. CHARLES: That reminds me actually of an experience that I had, a pair programming with Rob, probably about a year ago as we were making an interaction model for a select box. This was for a custom client. We actually stripped it away and we're like, "Let's just focus on what is the state machine behind this thing," so we drew it out on the board and it turned out that we were really just capturing the interaction apart from any rendering so we had a very strong model. With each state's transition, we were able to basically radiate that information with a screen reader in this case. But it was actually very trivial to do because we've actually forgotten about the DOM, forgotten about the fact that we were actually chasing a visual interaction and like I said, what is the actual user interaction? What is the information coming in and coming out? It turned out once we kind of flush that out and have developed that, hanging the interface on that skeleton was very easy and we could do it in multiple media. It feels like a similar concept where if your designers are very upfront about really exploring the information architecture of an application then being able to represent that information architecture in multiple forms becomes much easier because the joints and beams are very, very clear and they aren't bound to a particular form of representation. MARCY: Yeah, I think it a way that's definitely true. One challenge I would issue for this part of prototyping would be to consider all of the user inputs. Make sure that you're considering a keyboard user hitting an escape key to close that select or maybe they're using a screen reader on a touch device and like the single finger swipe, it's already allocated when that screen reader is running so if you have an interface that was only swipe left or right and there were no other affordances like buttons that you could actually activate, that would be an unusable interface to a mobile screen reader user. What really helps to make that information architecture stand up or hold out when you're developing it, like stay true to your vision through the process is making sure that you're considering all of those user inputs. Sometimes, developers aren't thinking about keyboard user so they're not thinking about focus styles, really trying to activate it another way. I do think that's a helpful exercise. ROBERT: Yeah, and to be fair at Frontend developers, we already have a lot to think about. It's just a lot to juggle so I can understand that's why we have tools like aXe. But what Charles is talking about, I think is actually kind of neat is we were experimenting with accessibility-first development so the people do TDD -- test driven development -- and I was trying to see if we could build something. I wanted to see if what we're writing would yield better software if we did it with an accessibility in mind from the outset. I think that's true. It was a more accessible typeahead. It was better, more well-defined user experience around the typeahead and it was because we thought about accessibility and all of the different edge cases. We really boil it down to the core problem. CHARLES: Right. We were driving it first with keys and nonstandard interaction methods. It meant that we actually got more clear interaction model lying underneath. It was decoupled from the actions that drove it completely because we had to support too from the get go. ROBERT: I thought that was neat. CHARLES: Yeah that was a fun exercise. You know, we should have blog about that because I think that actually results in better software. ROBERT: Yeah, I had a conference talk brewing in there somewhere. Just never got around to it. Talking about the web accessibility guidelines. There's different levels to it. Now, you have an A, AA, and AAA. What do those mean and where does that play into ARIA roles and stuff? MARCY: There's WCAG 2.0 and actually 2.1 is an update that they're working on right now but WCAG 2.0 is -- ROBERT: Oh, yeah. I saw that. MARCY: Yeah, there's some new stuff coming out. It's mainly for low-vision users and mobile touch things. But the WCAG 2.0 is the blessed standard that we're working with right now and the levels are different conformance levels. There's different things that you can achieve with A, AA, or AAA. Most people go for AA. AAA is pretty restrictive in what you can do and if you make it support WCAG 2.0 AA, it doesn't necessarily mean it's going to be intuitive to use. You could make it technically conformant but it won't necessarily be that beautiful or accessible. There's a bit of a dance that we have to do around that to meet these guidelines but do them in an intentional way so that we're actually making something usable. I think that goes back to that idea of craftsmanship and caring about your user to know if this actually going to work for them. There's a number of success criteria in WCAG that are broken up into different categories. There's perceivable, operable, understandable and robust. Within each of those, there's all kinds of different checkpoints that you can look at to inform how do I make this keyboard accessible. There's all kinds of really helpful documentation. That's the WCAG guidelines and within each of those, there are a number of different ways that you can code something. As I'm sure you know, there are infinite ways to code the same thing, pretty much and part of what that cover is techniques for making things accessible. They'll tell you all about Native HTML and what tools you can use within that standard. Then there's this other standard called WAI-ARIA and that's the Web Accessibility Initiative – Accessible Rich Internet Applications. That was originally created back in the day when we didn't have as many browser APIs and we didn't have great ways to expose accessibility information to screen readers. They made this API in browsers that implemented that you can actually bolt on some of the same information that you get from HTML. It's helpful if you're writing as VG or XML, where you just don't have those built in semantics so we have things ARIA role states and properties. You may have seen things like 'role="button"' or 'role="main"' or 'role="search"'. You might see that somewhere and that is just exposing programmatically bolting on a role to any element. You could put on 'div role="button"' and there's a little more that goes into that to make it an accessible button. Anytime we mentioned -- ROBERT: The tab index. MARCY: Yeah, the tab index. You have to make sure you have a keyboard event but that would be a programmatic way to create a button element. You should always start with the native button element because you get all that stuff for free but ARIA gives us an API to actually implement accessibility information. You'll see those techniques come up a lot in WCAG of how you can accomplish the same thing multiple ways. Those are some of the things that we test for in our animated tests in aXe. We check to make sure that you've only use roles that are actual roles because there is a set standard of them. We check to make sure that all of the ARIA values that you might use are actually allowed for that. Sometimes, if you're using 'role="list"' for whatever reason, you can't use a real list. It is possible to create a list with ARIA but if you had the wrong child role or something, that's a pretty easy thing that we can flag with aXe so we're sort of saving you from yourself. It helps me sometimes when I get a role wrong because we're human and we do make mistakes. There's a lot of things to remember so that's pretty key technique that aXe will help you with. That's making sure that your ARIAs used correctly because it is pretty easy -- ROBERT: That's really nice. MARCY: -- to get it wrong, to be honest. ROBERT: Yes. I've definitely done that. Being through the spec document is not the most fun. Trying to read the standards language is a little bit complicated so having a tool like aXe is really helpful for me to pick my way through it like, "aXe will tell me that this is wrong," so it narrows the problem set down for me where I can go and look at the standard and kind of tunnel vision in on that one, rather than get overwhelmed looking at that whole standard documents like there's so much here. MARCY: Yes, there is. One thing that might help with the is the initiative that people are working on called the ARIA Practices Guide, the ARIA Authoring Practices and it sort of breaks down these techniques into what is the keyboard navigation model for that component or it will break it into known patterns. This is really helpful also for designers to know what are some known patterns and how can I implement accessibly. They can really help you jumpstart to using those patterns with this more easily digestible information to tell you how to do it correctly. That has come up in the last few years that I found really useful. ROBERT: That's awesome. I think I've seen this. Is it where they tell you like, "If you're going to reimplement a checkbox, here's how you would do with ARIA?" MARCY: Exactly. I've dropped a link in the chat so we'll expose that in the show notes, I'm sure. There's more resources out there now that are really helpful. There's another one called ARIA in HTML and that one is also from the W3C and it's a note on using ARIA and HTML. That one I found to be very useful as well because they tell you this first, second, third, fourth, and fifth rules of ARIA use. The first rule of ARIA use is if you can use a Native HTML element or attribute, you should absolutely use the built-in one first. That's a big -- ROBERT: Yeah, let's stop reinventing. MARCY: Yeah, you know it's tempting because you can create these custom elements and try to bolt on ARIA but the reality is that if you're trying to make it really backwards compatible, it's just so much easier to support the native things. There is an assisted technology called Dragon NaturallySpeaking, that's a dictation method and they didn't support ARIA until 2014 so you can easily imagine some of your user base with an older assistive technology. That might be completely broken for them so that's why we really push using the native things first just because of the better support on every platform. CHARLES: I have a question about the test automation. We've been talking a lot about aXe in the way that you can do this. Did I get it right? Are my roles correct? And all these things. What's an example of something that you just can't test for in an automated fashion? It just requires human interaction just to perceive it. I mean, this would be right now, kind of in the visual sphere, the state of automation for testing like did I break the layout still requires a human. What are examples of that in terms of accessible interface where you just do the things that you have to be on the lookout for that you can't cover with automation right now? MARCY: I think context and content are some of the most difficult like writing good all text. That can be really challenging just because what makes a good alt for an image and that supposed to be a text alternative to say, "This is something useful," and Facebook has solved that by using artificial intelligence to dynamically guess what's in an image. A blind colleague of mine that works there has written about and he said he always felt left out when he would read his news feed and someone would be talking about their first love or some kind of vague status update. With this new feature, it could say, "Oh, this image that they're talking about their love is a pepperoni pizza," or something where -- [Laughter] MARCY: It's really missing the context so they've started to do automatic all text. For us doing accessibility checks, we try to keep our solution as light weight as possible and without false positives. We can check whether you have an all attribute missing like you don't even have the alt attribute at all which means that the file name would be read in the screen reader which is often terrible, depending on what your filenames are so we can check if that's missing but we can't really tell you what would make a better alt attribute, if you already have one. That's one is a bit difficult. There's another one that we're working on right now with color contrast where we can't really tell if you have a background image that's behind some text. If it has multiple pixel color values in it, even if we could read those colors, it gets really hard for us to say whether text meets color contrast when it's over an image for multiple reasons. That one's a bit tricky. I think there are some other examples throughout WCAG that we can only automate. Depending on which rule set you're using, we estimate between 30% to 40% of issues, we can actually catch with automated tests so there is quite a bit that we still need humans for. But however, I think some of these really basic ones that we can check to help you do those easy wins so that you're not getting messed up by using the attribute Aria-role when it's just role. Those kind of things. It's like we're helping you so you can save that time for those more complex task that might require a human. There's definitely no substitute for trying to use the keyboard to make sure that your app is usable from the keyboard. Test it with a screen reader, you can find people in the web accessibility Slack that might be willing to help you test it, if you're extra nice or maybe you can give them a gift card or something. There is an organization called Knowbility and they have this thing called Access Works where if you need to find a user with a disability to deduce a user testing for you because that's a great thing to do. It's very important. They can help you, as a business think up with someone who can test your app. I would definitely check out Access Works. That's really what's the missing piece. As a developer, I'm okay using a screen reader after doing accessibility for a few years but it's not my primary way of navigating so it's really helpful to have real users to test your app and that's a good way to find someone to actually test it. That sort of makes up the rest so you can get that really valuable feedback. ROBERT: I'm a firm believer in testing but also, I really do think a lot of accessibility work is just kind of empathy building and the way you do that is just sit down and actually use this assistive tech that these people will be using. In that way, you can understand as you're building it, how somebody might move their screen or cursor over the top of this and you can start to think about what the screen will read off and stuff like that. I think using a screen reader as a developer is powerful. But I agree, it will never reach the level like my mom that has been using a screen reader for seven years now. I'll never be able to use it as well as she does. It actually putting in the hands of people that do this day-to-day and live this. A far better idea and that goes beyond accessibility too. You want to user test all your apps anyway. MARCY: Yeah, exactly. I think that should be a big thing that we demand just from our organizations like how you were saying it was kind of controversial. I feel like user testing is another flavor of that where we have a bit of emotional tide of these things that we create and we want them to be perfect in the way that we have envisioned but not everyone interacts with things the same and it's really humbling to watch someone use something that you made and have it completely not get it at all. I think that's a really valuable experience. I've watched my mom or my dad or people try to use something that we assume is really intuitive and it's just not. We look at the web all day -- day-in and day-out being professionals and it's really helpful to show it to people who maybe aren't as fluent, aren't digital natives like that. CHARLES: We talked about actual user testing. We talked about the checking where you render your application and you run a set of checks. Do you have any experience with actually -- this is kind of an idea that just occurred to me, although we did a little bit of it when we were doing native applications -- using the accessible interfaces to actually drive your acceptance tests? Is that anything that you have experience with? Because it seems like on the face of it, you've got this assistive technology that surfaces the key levers of your application so is it a good idea to grab those levers from within your test case? Within your acceptance test to manipulate your application and thereby kind of front load your accessibility because in order to verify it, you must have those levers in place. MARCY: Yeah, from understanding your question correctly, you're wanting to just run your tests using accessibility features? CHARLES: Yes. For example, when we write our acceptance tests in our application, what we do is as part of setting them up, say we want to click here and I want to enter this text into this text box and I want to move this over here and that implies actually dispatching mouse events, keyboard events and then also being able to find the elements in the DOM that I want to dispatch those events on so we're kind of doing it in, I think we use CSS selectors to find them and then we use the jQuery event interface to actually create the events and send them to those elements. But it seems that part of ARIA roles or something else is like identifying the role that this element has in your application and basically saying, "For my test cases, I'm going to use these roles and I'm going to use these things and I'm going to use different access methods, keyboard mouse or whatever to manipulate my interface." Does that makes sense? MARCY: Yeah. ROBERT: I think this makes sense in the native world where in order to get the label, I think you have to use the accessibility label. CHARLES: They do that when you're functionally testing iOS apps so why not -- ROBERT: Does it port to the web, basically. CHARLES: Yeah, does that port to the web? MARCY: It does -- CHARLES: It's really long, way of saying that, I guess. Sorry you all. [Laughter] MARCY: No, and I wanted to clarify because I was wondering if you're talking about driving it with actual assistive technology, which we can't quite yet. We don't have any tools for that. But yes, you should -- ROBERT: We should explore that in Ember. MARCY: Yeah, we just don't have the hooks for that. Maybe Python and NVDAs, since it's open source, maybe AppleScripts. CHARLES: What would that look like to drive it with assistive technologies? ROBERT: We talked to some people at Apple with Ember accessibility team and if I remember correctly, we could only drive VoiceOver on MacOS with AppleScripts but there was no way to do it in any other way so you only could do it with VoiceOver on MacOS and that was still kind of murky. MARCY: Yeah, exactly. The idea would be, rather than just testing the browser, we would actually be able to run a simulator programmatically, to know is the screen reader actually exposing this information. Because a lot of it is there are things that get lost in translation, sometimes where we're following best practices and standards because we have this agreement that people who implement browsers and screen readers are going to follow those standards. It's definitely is not always smooth sailing with that. But there's sort of this disconnect between the browser testing and then actually firing it up in the screen reader and make sure it worked. We take that on faith a lot of time, which is getting back to your original question, why it's so valuable to have tests that use these interaction methods. Absolutely, either in your unit tests or even in your integration test, they can live in either place to have tests that assert and closes with the escape key or it operates with the enter key or whatever the user interaction should be, that we have tests that assert that because that way, if you leave your team or heaven forbid, you got hit by a bus or something, you have a test coverage that makes a contract of how this component should work and you have accessibility support, actually built into your test infrastructure. That is super valuable. At least we know that that part of it is there. We know we can drive it from the keyboard, which is how a lot of screen readers work. They operate on top of the keyboard so we can get really far just by having basic keyboard support. Then, if you pull in an API like axe-core, you can have it tell you if you were using ARIA wrong or something. It's sort of a combination of both where those feature tests in your actual project where you're writing something that it works with the escape key, those are custom tests for your application. I find that they're really valuable just to have in there, especially if you work on a component library or something reusable so that everybody who is contributing knows how this thing is supposed to work. I think that is really valuable. ROBERT: Absolutely. I want to talk about accessibility in single-page apps. The problem with accessibility in single-page apps is while using a screen reader, you click a link and to the screen reader user, all it says is the link was pressed. They don't actually know that the content has changed. But in Ember, we kind of solve this by focusing the outlet that has changed but in other frameworks, in your experience everywhere else, how do you combat this? What are the best ways of attacking this? CHARLES: Yeah, what are the problems that you encounter in single-page applications? MARCY: I've done quite a bit of research and blogging and conference talks on this. I'm working on the Angular team for a while. The issue with the single-page app is the page isn't being refreshed when you make a raving change or something happens dynamically. The user's focus is never refresh to the top of the page so they don't hear a title change or things like that. There's different techniques that you can employ to make that experience more accessible. The first and foremost tool to have in your toolbox is focus management so that you're programmatically sending the user's focus to this new content. Say, I have a sidebar with links in it and I click one of them, I can send focus to content wherever it loaded on the page. That way, they are both alerted to the new content because depending on where you send it. There's different techniques for this but often, we will send focus to the wrapping element so that everything will be read aloud and you can accomplish that by using tab index of -1 in your HTML. That will make this wrapper catch the focus, essentially but it won't add it to the tab order of the entire page. That's a technique that we used to shuffle focus around. I've also seen people use what's called an ARIA Live Region where you have this element somewhere on your page that's not visible. It has to be rendered so you can't use 'display: none' but you can basically pipe messages to these live regions to announce what's happening on the screen. I've just saw a React example where they put an ARIA Live attribute just on that wrapping element, instead of the focus management so anytime new content went into that element, it would just be announced. The challenge with that is that you can't always control everything on the page. That works if you control everything and you know that only this one element is getting updated at the time. But often, we work in this big ecosystem where there's a bunch of things happening. Depending on how complex your app is, you might need some sort of a focus manager, some sort of a utility that will keep track of what's focused and routed around at a correct place. That's the biggest tool for creating accessible single-page apps, that's focused management. I mean, not only for the reading content purpose but also to have their focus in the more accurate place so if they hit tab or they try to start interacting with something that they're in the right part of the page. A good example, if you think about like a modal window -- a modal window may open as a new layer over something -- that requires focus management on open so that your focus is sent into it, either to the first focusable element or to the wrapper. Then when you hit escape or close the modal, it just send your focus back. ROBERT: To the previously focused element, right? MARCY: Exactly, so that if you are using a keyboard and you can't actually use a trackpad or a mouse to get back then you're in the right place or if you're screen reader user and you can't even see the screen, then you're always in the right spot. That's actually, I think really cool. Something that's become more common place with dynamic JavaScript apps is that we can do these really cool focus management techniques. I think they're really cool, they can be challenging but that is something that we definitely need to think about as developers of single-page apps. ROBERT: Absolutely, especially since none of the single-page app frameworks out there were libraries. Actually maybe with the exception of your work on Angular, they don't come with a router focused-library built in so this is something that you have to actually think about and then pull in and do yourself. Does Angular have it, by default? MARCY: No, we never added a focus manager utility. There were some things to try and clean up that HTML, which ended up being, honestly worse than the original problem. But I've written a blog post about focus management techniques. I just dropped that in the chat. There's a smashing magazine article I wrote and it really is framework-agnostic so it sort of covers all of the things that you need to think about if you're writing a client-rendered application using Ember, React or Angular. It is something that we have to think about as developers because from the framework level, it's impossible to know what the right situation would be in your app in a given moment so we can only get so far with magic at the framework level. It's something I would like to see more of. Maybe if there is some sort of a layer manager, I think that is a tool that someone could write that would be super useful -- to make sort of an intelligent layer managing system for focus management. I've heard the Facebook team talked about how they do it internally but it's not open source so I have yet to see an open source solution for this. We have to tackle it in our own apps but once you know that that's the thing, you can really make sure that you're covering it. If you have someone with a visual disability or impairment that try and use your app, they'll probably uncover that problem pretty quickly. That's the value of user testing in case you forget. Maybe there's a few views -- ROBERT: Need to sell it. MARCY: Yeah, or maybe with your application, if you don't have visible focus styles turned on, you might not see that the focus isn't being sent. That is one trick, I will tell you in development. If you're working with focus management, turn the focus outlines on and then if you were trying to send focus before it got fully rendered or something because it has to actually be rendered to catch the focus. That is good debug flag, if you can all agree on the focus styles, for all users. I found that to be really useful in our app. You just to have those turned on so you can debug it. ROBERT: And make it really loud like this is a giant red outline. MARCY: Yeah, then you'll know, if you forgot to add tab index of -1, to make it catch the focus or like I said, maybe there's a rendering thing where you need to wait a tick by using a set time out or something. That is a good technique that I've used recently. ROBERT: Awesome. Basically, what it boils down to in single-page apps is manage your focus and enhance your focus, some might say. MARCY: Yeah, let's think about keyboard ergonomics, like if you are doing things dynamically on the screen and then you want to start typing, I think the most common example I see is autofocus. The developers, even if they aren't thinking about accessibility, they'll ask for autofocus. That in a way is focus management. The difference with autofocus is that you can only use it once and it will send your focus there automatically. But in a similar way, that's the idea of what we want is to get the user's focus point into the right spot so that they can do the right activity on the screen and they know what content they're looking at. ROBERT: Right. Sometimes, it's like navigating around a website with your keyboard, that's like power users who have Vim or Emacs or anybody that's a power user of computer that doesn't like to leave the home row, you can make your application awesome for you to use and also lay the groundwork for accessibility, if you can navigate your website with just a keyboard. MARCY: Exactly. ROBERT: Let's try to pitch it to people in that way. It's still a developer problem. CHARLES: I like that because it really highlights the fact that there is this kind of deep interaction model. The user actually is focused on one thing at a time in the application and if you track that, then it's going to be a benefit for all of your users. If you are deliberate about thinking like this is the subject of interest at this moment. You're just going to reap a lot of benefit for everybody. ROBERT: Keep coming back to it, building accessible applications yields a better application for everybody. MARCY: Absolutely. It might enable you to support some futuristic device that you haven't even thought of yet. If you have your actions decoupled from the actual input and you can do everything declaratively, that really makes it easier to try and support of use cases you haven't thought of like we need to borrow up that other keyboard combination or some touch device. It just really helps to not have everything buried in a jQuery event. ROBERT: Yes. [Laughter] MARCY: Like, "Oh, man I need to call that same functionality for multiple events. Crap." You need to decouple that real quick. ROBERT: "Let's obstruct this." CHARLES: Right. I think we're about the time. I know you've got a hard stop. You got some skiing to do. MARCY: I do. CHARLES: So we will let you get up on the mountain but thank you so much for coming by. This is been a great conversation. ROBERT: Yes, thank you for dropping all the knowledge. CHARLES: Yeah, I'm feeling lots of knowledge right on top of my head -- MARCY: Awesome. CHARLES: -- That I got to go and process. But for everybody else out there, I would say go experiment with aXe. The idea is going to be easy for developers. I know I'm going to experiment with it and then you said, there was a browser extension as well to help you out and probably call out every website that you ever use, right? MARCY: I'm dropping some links for you, just now. CHARLES: There's some links to go along with the knowledge so go check them out and you are @MarcySutton on Twitter? MARCY: That is correct. CHARLES: All right. Fantastic. Thank you so much for coming by. MARCY: Yeah, no problem. Thanks so much for having me.

今回はAccSellクリッピング拾い読みで、電子書籍のアクセシビリティー、手話映像の自動生成による天気予報、WAI-ARIAを使って絵文字をアクセシブルにする方法について話しています。 写真：ノートパソコンに映っているのは、ポッドキャスト内で紹介している「NHK気象情報 手話CG」のページで実際に手話中の動画が流れている画面です。これほんとすごい。でもまだこの女性に名前はない（開発している人たちはなんて呼んでいるんやろう）。 オープニング・トーク 今回のizuizuからのお題は「自動改札」です。が、自動でない改札についてもいろいろ話しています。 AccSellクリッピング拾い読み AccSellクリッピングに掲載した話題の中からAccSellの3人が気になったものを紹介するAccSellクリッピング拾い読み、まず中根が「合理的な配慮とは何か、を考えてみる～電子書籍のアクセシビリティ」という記事を取り上げています。この記事では、「電子書籍アクセシビリティの研究」という電子書籍で示されている、音声合成による誤った読み上げに関する取り組みについて取り上げていますが、そのような方向性の問題点などについて話しています。 つづいてizuizuが、「NHK、気象情報の手話CG映像の自動生成システムを開発 ～検証サイトを公開」という記事を取り上げています。実際に自動生成された手話映像を検証サイトで見ることができますので、皆さんも見てみてください。 そして植木が、 "Accessible emoji" という記事を取り上げて、Unicodeに含まれている絵文字をアクセシブルにする手法について紹介しています。 収録後記 テレビの解説放送視聴熱が止まないです。なにげにNHK大河ドラマもちょいちょいおかしいことを言っているので試してみてください（さいっ！） (山本 和泉） 誤読ゼロ問題は、ホントにどげんかせんといかんですなあ。それはともかく、ただいまアメリカのサンディエゴに来ています。今年も「CSUN」という世界最大級のカンファレンスに参加するためです。いよいよ明日から本番。時差ボケに負けないようにがんばります！ (植木 真） 2月は、AccSellクリッピングの更新がすっかり滞ってしまいました。結構興味深い話題は多いのですが、なかなか目を通して掲載するところまでいきませんでした。2月の気ぜわしさの原因、確定申告を本日終わらせてきたので、3月はもう少しがんばれると思います。 (まあ年度末のよく分からない忙しさというのもあるので断言はできないのですが。) (中根 雅文） AccSellクリッピングの関連記事 [電子書籍] 「電子書籍アクセシビリティの研究」 (Amazon.co.jp) Accessible emoji (Tink) 『電子書籍アクセシビリティの研究』公刊記念シンポジウム (覚え書き | @kazuhito) 合理的な配慮とは何か、を考えてみる～電子書籍のアクセシビリティ (#a11yTips: Webアクセシビリティ・情報バリアフリー) NHK、気象情報の手話CG映像の自動生成システムを開発 ～検証サイトを公開 (PC Watch)

Bart continues his current dual path of teaching. We learn how to compare JavaScript objects (spoiler, you can't use == or === to do it). After that he teaches us how using WAI-ARIA as we develop our code will make it accessible to screen readers and other assistive devices. We don't do any real coding in this section; instead he explains the foundation for what we'll be doing in the future.

Bart continues his current dual path of teaching. We learn how to compare JavaScript objects (spoiler, you can't use == or === to do it). After that he teaches us how using WAI-ARIA as we develop our code will make it accessible to screen readers and other assistive devices. We don't do any real coding in this section; instead he explains the foundation for what we'll be doing in the future.

関連リンク 2016-11-15のJS: TypeScript 2.1RC、Node.js v7.1.0リリース - JSer.info TypeScript 2.1 RC: Better Inference, Async Functions, and More | TypeScript FLOCSSを使ってCSSファイルを20,000行から9,000行にした話 - Qiita GitHub - hiloki/flocss: CSS organization methodology. Managing CSS Projects with ITCSS // Speaker Deck 2016年、Web Audio API はどう変わったのか? | g200kg Music & Software Improving Perceived Performance with Multiple Background Images – CSS Wizardry – CSS, OOCSS, front-end architecture, performance and more, by Harry Roberts deck.gl 2016-11-22のJS: Firefox 50、React v15.4.0、Custom Element v1 - JSer.info Mitigating MIME Confusion Attacks in Firefox | Mozilla Security Blog React v15.4.0 - React Blog User Timing API: あなたの Web アプリをもっと理解するために - HTML5 Rocks GitHub - paulirish/pwmetrics: Progressive web metrics at your fingertipz 2016-11-29のJS: Node.js v7.2.0、Yarnでオフラインインストール - JSer.info Running Yarn offline | Yarn Blog Understanding JavaScript Micro-Templating – WDstack – Medium Khan Academy | Free Online Courses, Lessons & Practice katatema.js - ✘╹◡╹✘ GitHub - nfl/react-helmet: A document head manager for React React at Product Hunt // Speaker Deck Reframe.js GitHub - nuxt/nuxt.js: A minimalistic framework for server-rendered Vue.js applications (inspired by Next.js) GitHub - moroshko/react-autosuggest: WAI-ARIA compliant React autosuggest component Brad Frost Online Store デスクトップ版Firefox 57で拡張機能はWebExtensionsベースに限定化 - Mozilla Flux

Brian Kardell (@briankardell) joins Erik, Justin, and Danny on the panel along with our guest Marcy Sutton (@MarcySutton) in a discussion on WAI ARIA attributes & how we should or shouldn't be using these in the context of our applications. Resources Marcy's EggHead.io class - https://egghead.io/courses/start-building-accessible-web-applications-today AXE 2.0 - http://www.deque.com/blog/introducing-axe-2-0/ Best practices - https://w3c.github.io/aria-practices/#toc Examples - https://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#aria_ex Smashing article from 2014 - https://www.smashingmagazine.com/2014/07/the-wai-forward/ Getting started - http://a11yproject.com/posts/getting-started-aria/ Harvard University guide to online accessibility - http://accessibility.huit.harvard.edu/use-accessible-design-patterns Marcy's performance post - https://marcysutton.com/accessibility-and-performance/ Free course on Web Accessibility - https://www.udacity.com/course/web-accessibility--ud891 Chrome A11y Inspector - http://bit.ly/chrome-a11y JSAir on Axe - https://javascriptair.com/episodes/2016-07-13/ Accessibility API's by Leonie Watson - https://www.smashingmagazine.com/2015/03/web-accessibility-with-accessibility-api/ Web AIM screen reader survey - http://webaim.org/projects/screenreadersurvey6/ What does accessibility supported mean? https://www.paciellogroup.com/blog/2016/08/what-does-accessibility-supported-mean/

今回は、植木と中根が注目した、2015年のアクセシビリティー関連トピックスを、BAの太田 良典さんにもご参加いただいて振り返っています。また、2016年2月11日に開催予定の、AccSell Meetup 011についても紹介しています。 写真：会議室での収録風景。左下から時計回りで、顔をピースで覆っているいずいず、ゲストの太田さんは今回はまじめな表情でカメラ目線、中根はいつも通り、なにかを企んでそうな笑顔な植木。 オープニング・トーク 今回のizuizuからのお題は、「2015年に印象に残った食べ物／飲み物」です。 2015年アクセシビリティー重大ニュース この1年間にAccSellクリッピングで取り上げた話題から、植木と中根が特に注目したものを振り返っています。たまたま別件でその場に居合わせた、BAの太田 良典さんにも(無理矢理)加わっていただいています。 取り上げた話題は以下の12本です。 (括弧内は、その話題を紹介している、または関連しているポッドキャストへのリンクです。) Google Document, Spreadsheet, Slides, Driveがスクリーン・リーダーで利用可能に (第66回) Webアクセシビリティーに関する書籍が続々刊行 (第66回、第81回) アクセシビリティーに関連するイベントやワークショップが全国各地で開催 (第71回) FoundationやBootstrapなどCSSフレームワークでWAI-ARIA対応が進む (第76回、第82回) Webアクセシビリティー・テストのためのJavaScriptライブラリー、aXe (Accessibility Engine) をDeque Systemsがオープンソースで一般公開 Authoring Tool Accessibility Guidelines (ATAG) 2.0がW3C勧告へ User Agent Accessibility Guidelines (UAAG) 2.0はWorking Group Noteに (第78回) MicrosoftやFacebookなどIT企業や大学が、技術系の学生のアクセシビリティー教育を推進する目的のワーキング・グループ、Teaching Accessibilityを設立 (第74回) アメリカのAmazonやNetflixのオンライン動画配信サービスで、キャプションや音声解説を提供する動きが加速 (第80回) 日本国内で高年齢層でのインターネット利用が今年も拡大傾向 マラケシュ条約の批准国が13カ国に 家庭用ゲーム機のアクセシビリティー向上の動き 今回のゲスト 太田 良典 (おおた よしのり) さん BA システムソリューション部 セキュリティスペシャリスト / アクセシビリティスペシャリスト ウェブアクセシビリティ基盤委員会(WAIC) 実装作業部会副主査 / JIS X 8341-3改正原案作成委員会委員 HTML4.01のW3C仕様書を翻訳した「HTML4仕様書邦訳計画補完委員会」の委員を務めた後、2001年にBAに参加。Web技術の分野で幅広い専門性を持ち、セキュリティ分野においては「第二回IPA賞（情報セキュリティ部門）」を受賞。アクセシビリティ分野では、ウェブアクセシビリティ基盤委員会(WAIC)の委員として活動している。著書（共著）に「デザイニングWebアクセシビリティ」など。 収録後記 今年最後のポッドキャスト！！今年も楽しかったですです！！！ありがとうございます！！！ほんま風が来てますね、きてますきてます（マリック風）。来年もどうぞよろしくお願いいたします！！！ (山本 和泉） AccSellのサイトに掲載している情報量なんかから見ても、確かにアクセシビリティーに関する話題は多く、「風」は吹いているのかもしれません。でも、このサイトのアクセス状況を見ると、実は大した数字ではありません。ということは、世間の興味が増しているのに、このサイトはそれに答えられるような情報現にはなっていないということなのだと思います。2016年は、そんな世間の動きを支えられるような存在のサイトにできるように、知恵を絞っていこうと思います。というか皆さんの知恵を貸してください。今年もありがとうございました。どうぞ良い新年をお迎えください。 (中根 雅文） 今回のタイトル通り、2015年は「風」を感じた年でした。自分が吹かせた「風」もありましたが、2016年もそれを含めて「風」がさらに吹くような一年になればと思います。安心してください、仕掛けていきますよ！ (植木 真） AccSellクリッピングの関連記事 新刊書籍 :「デザイニングWebアクセシビリティ - アクセシブルな設計やコンテンツのための実践Q&A」 新刊書籍: 「コーディングWebアクセシビリティ - WAI-ARIAで実現するマルチデバイス環境のWebアプリケーション」 Getting started with Google Drive using a screen reader (YouTube) Getting started with Google Slides using a screen reader (YouTube) Getting started with Google Docs using a screen reader (YouTube) Getting started with Google Sheets using a screen reader (YouTube) PS4 System Update 2.50 Available Tomorrow, Features Detailed (PlayStation.Blog) PlayStation®Vita/PlayStation®TV システムソフトウェア アップデート (プレイステーション® オフィシャルサイト) Netflix Makes Daredevil Accessible to the Blind After Complaints (TIME) An update on office solutions in the browser and on mobile (Marco's Accessibility Blog) Accessibility Testing Goes Open Source and Mainstream (Deque) 平成26年通信利用動向調査の結果 (総務省) Microsoft, Facebook, and others want to make accessibility a bigger priority (The Verge) アクセシビリティ対応に役立つフロントエンドフレームワーク5選！ (RiARiSE) Vol.1-Bootstrap4に学ぶ、アクセシビリティ(WAI-ARIA)対応のレスポンシブWebサイト制作 (RiARiSE) Vol.2 – Bootstrap4に学ぶ、アクセシビリティ(WAI-ARIA)対応のレスポンシブWebサイト制作 (RiARiSE) Vol.3 – Bootstrap4に学ぶ、アクセシビリティ(WAI-ARIA)対応のレスポンシブWebサイト制作 (RiARiSE) Authoring Tool Accessibility Guidelines (ATAG) 2.0 is a W3C Recommendation (w3c-wai-ig@w3.org) [電子書籍] わかりやすい「WAI-ARIA 1.0」仕様解説書 (Amazon.co.jp) Amazon commits to adding captions to over 190,000 movies and TV shows (The Verge) Foundation 6 Is Here! (ZURB Blog) UAAG 2.0 and UAAG 2.0 Reference published as W3C Working Group Notes (w3c-wai-ig@w3.org) Video Game Console Accessibility for the Blind takes ONE Step Forward (Brandon Cole .Net) Brazil Ratifies "Books for Blind" Marrakesh Treaty (YouTube)

Schepp, Stefan und Peter debattierten Web Components und verteilten die allwöchentliche Ladung Links. Schaunotizen [00:00:10] Web Components und Gremlin.js Angeregt durch das Erscheinen der Minimal-Web-Components-Library Gremlin.js (nicht zu verwechseln mit dem Test-Tool Gremlins.js) plaudern wir über Web Components allgemein. Neben Web Components in unserem Alltag (nicht existent) geht es um Custom Elements, WAI-ARIA, Mutation Observers, […]

今回は、AccSellクリッピング拾い読みで、Foundationの新バージョンにおけるWAI-ARIA対応、日本国内のテレビ放送における字幕放送などの状況、イギリスBBCラジオが音声解説を取り上げた番組について話しています。 写真：久々にAccSellの3人がリアルにそろっての収録。左から時計回りに録音ミキサーを調整している中根、昭和のアイドルっぽいポーズと表情の植木、パソコンに隠れきれていないいずいずです。 オープニング・トーク 今回のizuizuからのお代は、「今年やり残していることで今年中にやっておきたいこと」です。 AccSellクリッピング拾い読み 最近AccSellクリッピングで紹介した話題の中から、AccSellの3人が気になった話題を取り上げるAccSellクリッピング拾い読み、まず植木がフロントエンド・フレームワークのFoundationの新バージョンがWAI-ARIAを活用してアクセシビリティーを向上させているという話題を取り上げています。 つづいてizuizuが、総務省が発表した国内のテレビ放送における字幕放送、解説放送、手話放送の実施状況について取り上げています。 そして中根が、イギリスBBCラジオで放送された音声解説に関する番組を紹介しています。 収録後記 しわっす！　師走ですね～、年末進行の季節ですね～。都内も少しずつ冬っぽい天候になってきましたね～。風邪ひかないように気をつけましょうね～。ね、ハニー？　...は、ハニー？？ (植木 真） 僕は以前はテレビの音声解説は「別にあってもなくても良い」と思っていましたが、最近では結構な頻度で活用しています。テレビ番組に限らないのですが、100パーセント情報を得られているという状況を知らずにすべて分かった気になる、ということがよくあるのですが、音声解説を活用してみると、今まで認識できていなかったことがいかに多かったのかということに気づかされます。認識できていなくてもストーリーの流れは把握できるので困らないといえばそうなのですが、せっかくコンテンツを楽しむなら、作者がどんな工夫をしているのかということもしっかり理解できる音声解説は、やはりすごく重要だと感じる今日この頃です。 (中根 雅文） 2015年の年末ジャンポは前後賞あわせて10億円だそうですが、私は控えめな性格なので7億円で大丈夫なのでバラで買います。みなさんに福が来ますように！！　全然関係ないですが、先日香港に行ったときに信号の音響装置がとても印象的だったのでどこかで紹介できたらなーって思っています。信号の音響装置のチェックって旅の途中でちょっと楽しかったりしますよね！！！ (山本 和泉） AccSellクリッピングの関連記事 平成26年度の字幕放送等の実績 (総務省) Foundation 6 Is Here! (ZURB Blog) The Audio Describers (BBC)

今回は、先頃「わかりやすい「WAI-ARIA 1.0」仕様解説書」というKindle書籍を出版された、大藤 幹さんをゲストにお迎えして、WAI-ARIAなどについて話しています。 写真：名古屋在住の大藤幹さんから届いたシャチホコの写真と大藤さんです。 オープニング・トーク 今回のizuizuからのお代は、空港や飛行機に関連する「良い話」、ということで、中根が驚き(?)の体験を、植木が体験した入国審査でのトラブルを、そしてizuizuがちょっとした豆知識を話しています。 大藤 幹さんを交えて Webに関わるようになって20年という大藤さん、まずはどういった経緯でWebに関わるようになったのかというお話しをうかがっています。 大藤さんは、90年代後半には多くのW3Cの仕様書を日本語訳して公開していらっしゃいましたが、その中にはWCAG 1.0の日本語訳も含まれていました。Web標準やアクセシビリティーについて、大藤さんがどのように考えておられるのかというお話しもうかがっています。 そして、最近Kindleで出版された「わかりやすい「WAI-ARIA 1.0」仕様解説書」について、その内容に加えて、執筆の経緯などについてもお話しいただいています。関連して、WAI-ARIAについてもあれこれと話しています。 今回のゲスト 大藤 幹 (おおふじ みき) さん 2015年3月より名古屋在住。大学卒業後、複数のソフトハウスに勤務し、CADアプリケーション・航空関連システム・医療関連システム・マルチメディアタイトルなどの開発に携わる。1996年よりWebの基本技術に関する書籍の執筆を開始し、2000年に独立。その後、ウェブコンテンツJIS（JIS X 8341-3）ワーキング・グループ主査（多忙のため途中辞退）、情報通信アクセス協議会・ウェブアクセシビリティ作業部会委員、ウェブデザイン技能検定特別委員、技能五輪全国大会（ウェブデザイン職種）競技委員などを務める。現在の主な業務は、Webデザインに関連する書籍の執筆のほか、全国各地での講演・セミナー講師など。著書は『よくわかるHTML5+CSS3の教科書』『HTML5プロフェッショナル認定試験レベル1 対策テキスト＆問題集』など50冊を超える。 収録後記 ポッドキャストの中でもお話ししましたが、WAI-ARIA 1.0の仕様書は、こういった文書に慣れているつもりの僕にもかなり読みづらい、というか使いづらい仕様書だと思います。でも、大藤さんの新刊、「わかりやすい「WAI-ARIA 1.0」仕様解説書」は、必要なことがしっかりと整理され、まとめられています。僕のように、WAI-ARIAについてはなんとなく理解していたけれども詳しいことまで分かっているのか自信がない、という人にも、興味はあるけどなかなか手を付けられないでいる、という人にもお勧めの1冊です。 (中根 雅文） Webの勉強をはじめた時、特にCSSを本格的に勉強をはじめたときに、大藤さんの本にとても助けられ大藤さんの本で大きく（体型じゃない方）なりました。 (山本 和泉） ミキティーーーーーーーーーーーーーーーーーーーっ！　大藤さんとは、今までWebの話をしたことがほとんどなかったので、何だか新鮮でした。大藤さん、また呑みに行きましょう（笑） (植木 真）

今回は、まずTwitter拾い読みで、HTML5ベースでアクセシブルなメディア・プレイヤー、ユーザーのスキル向上とアクセシビリティー、Googleの各種Webアプリケーションのスクリーン・リーダー対応について話しています。後半では、株式会社ボーンデジタルの岡本 淳さん、BAの太田 良典さんをゲストにお迎えして、最近話題の書籍、「コーディングWebアクセシビリティ - WAI-ARIAで実現するマルチデバイス環境のWebアプリケーション」と「デザイニングWebアクセシビリティ - アクセシブルな設計とコンテンツのための実践アプローチ」についてお話しを伺っています。 AccSellの3人とゲストの岡本さん、太田さん。岡本さん以外は「コーディングWebアクセシビリティ」を持っています。前列のテーブルに座った左から太田さん、中根、植木。後ろに立っている、いずいずとちょっと緊張気味の岡本さん。太田さんの笑顔がすてきです！ Twitter拾い読み まず植木が、シンプルでアクセシブルな、HTML5ベースのメディア・プレイヤーPlyrについて取り上げています。GitHubで公開されているPlyr、なんと日本語のガイドも公開されています。 つづいてizuizuが、「アクセシビリティの利用者も意識を持つ方がみんなハッピー」というブログ記事を取り上げています。WAI-ARIAが普及していく中で、益々重要になってきそうな視点について話しています。 そして中根が、YouTubeで公開されたGoogleの各種WebアプリケーションをWindows用のスクリーン・リーダーNVDAとFirefoxの組み合わせで使うデモを紹介しています。 Google Drive Google Docs Google Slides Google Sheets 岡本 淳さん、太田 良典さんを交えて 後半では、ちょうど収録を行った3月27日に発売された書籍、「コーディングWebアクセシビリティ - WAI-ARIAで実現するマルチデバイス環境のWebアプリケーション」と、近々発売が予定されている書籍、「デザイニングWebアクセシビリティ - アクセシブルな設計とコンテンツのための実践アプローチ」を手がける編集者、岡本 淳さん、そしてこれらの書籍の翻訳や執筆をされている太田 良典さんに加わっていただいて、これらの書籍についてお話しを伺っています。この2タイトルの出版経緯、どのような人に向けたどんな内容の本なのか、翻訳、執筆に当たっての苦労話などをお訊きしています。 今回のゲスト 岡本 淳 (おかもと じゅん) さん 株式会社ボーンデジタル 書籍編集者。マーケティングリサーチャー、進路指導教員、就転職コンサルタントを経て、2006年より現職。企業のWeb制作人材コンサルティング、制作スキル判定ロジックや検定事業の開発、トレーニングやセミナーの企画・運営の経験を通じて、Web制作に従事する人たちが必要とする書籍づくりを目指し推進している。趣味はオートキャンプと低山ハイク。 太田 良典 (おおた よしのり) さん BA システムソリューション部 セキュリティスペシャリスト / アクセシビリティスペシャリスト ウェブアクセシビリティ基盤委員会(WAIC) 実装作業部会副主査 / JIS X 8341-3改正原案作成委員会委員 HTML4.01のW3C仕様書を翻訳した「HTML4仕様書邦訳計画補完委員会」の委員を務めた後、2001年にBAに参加。Web技術の分野で幅広い専門性を持ち、セキュリティ分野においては「第二回IPA賞（情報セキュリティ部門）」を受賞。アクセシビリティ分野では、ウェブアクセシビリティ基盤委員会(WAIC)の委員として活動している。著書（共著）に「Dreamweaverプロフェッショナル・スタイル」「ウェブの仕事力が上がる標準ガイドブック5Webプログラミング」など。 収録後記 「コーディングWebアクセシビリティ」、いよいよ店頭にも並び始めましたね。書店で見かけるたびに、目立つところへ移動させて販促＆メンテナンスに励んでいることは内緒です（笑）　次の「デザイニングWebアクセシビリティ」にも期待が膨らむ今日この頃、例年になく多忙だった年度末を何となく乗り切れた気がしております。 (植木 真） 岡本さんのSNSの投稿を見ていると、いつもキャンプに行っているので、岡本さんのことを「キャンプさん」と脳内で勝手に呼んでいることは内緒です（笑）。Web系の技術書の編集って、ほんと大変そうだなぁすごいなぁって遠くからいつも尊敬しています。キャンプさん。 (山本 和泉） ポッドキャストの中で紹介しましたが、WAI-ARIAへのユーザー・エージェント側の対応もだいぶ進んできていますし、サイトによってはこれを積極的に活用するようにもなってきています。そして、やはりポッドキャストの中で話が出たように、この新しい仕組みにユーザーも追いついていかないといけないという側面もあります。WAI-ARIAを適切に使ったアクセシブルなサイトが増えることを願いつつ、こういったこともしっかりと考えていかなければいけないなあと改めて感じています。そしてそんなWAI-ARIAを理解するのには、今回取り上げた書籍がきっと有効なはずです。皆さんの感想など、ぜひお聞かせください。 (中根 雅文） AccSellクリッピングの関連記事 Getting started with Google Drive using a screen reader (YouTube) Getting started with Google Slides using a screen reader (YouTube) Getting started with Google Docs using a screen reader (YouTube) Getting started with Google Sheets using a screen reader (YouTube) Plyr - A simple HTML5 media player (plyr.io) アクセシビリティの利用者も意識を持つ方がみんなハッピー (500 Internal Error )

今回は、Twitter拾い読みでPDFのアクセシビリティー、WAI-ARIA 1.0の邦訳版、音を検知する聴覚障害者向けアプリについて取り上げています。そして、2月11日に開催したAccSell Meetup 008を振り返っています。 今回は植木が手前で自撮り風。後ろには、笑顔の中根と、歌舞伎揚げ2個を両手に持って頭に合わせてネズミっぽいキャラクター風のizuizuです。 Twitter拾い読み まず植木が、オーストラリア政府によるPDFアクセシビリティーに関する指針が更新されたという記事を取り上げて、PDFのアクセシビリティーについても話しています。 つづいてizuizuが、「WAI-ARIA 1.0の日本語訳ができました」というブログ記事を取り上げています。文字通り、WAI-ARIA 1.0の日本語訳ができた、という記事ですが、関連してWAI-ARIAについて簡単に解説しています。 最後に中根が、OtoSenseという、音を検知して可視化して伝える、聴覚障害者向けのアプリケーションを紹介しています。 AccSell Meetup 008振り返り そして、2月11日に開催したAccSell Meetup 008を簡単に振り返っています。30名近くの方にご参加いただいた今回のAccSell Meetupの様子を少しだけ紹介しています。 なお、当日は複数の方がTwitterでもいろいろと投稿してくださいました。その時のツイートのまとめも作られていますので、ぜひご覧ください。 収録後記 オープニング・トークで話題になった牡蠣、嫌いじゃないのに食べられない (食べる勇気がない) んですよねえ。なんか損している気分です。ものすごく好き、というわけではないところが救いですが……。(中根 雅文） 2月第1週の大阪、神戸、そして第2週の東京と、セミナーへの登壇が合わせて5本。今週に入って、少し落ち着きを取り戻したと思ったのも束の間、来週末から海外出張ということでドタバタしております。忙しいのはいいことですが、無事に今月の仕事を終えられるかどうか...。いや、終わらせます。きっちり終わらせてから、CSUNへ行くのだ！ (植木 真） いちごのおいしい季節ですね！いちごばんざい！いちごラブ！ 今年は6年ぶりの確定申告なのですが、まだ準備できていません。いちご食べてがんばります！ (山本 和泉） AccSellクリッピングの関連記事 PDF accessibility: new guidance issued (Access iQ) WAI-ARIA 1.0の日本語訳ができました (水底の血) OtoSense

Jon and Trevan answer questions from Reddit! Show Links Reddit thread WAI-ARIA roles Web Content Accessibility Guidelines (WCAG) Tenon.io Solve this pen! Make it work in IE10 and we’ll give you a shoutout or something David Walsh’s CSS Flip Animation article Front-end Job Interview Questions Why Brad Frost is not a JavaScript developer Storyland Studios site […]

In Episode 9, ‘Web Accessibility for JavaScript Components and Custom Elements'. Steve Faulkner (@stevefaulkner) from The Paciello Group and Marcy Sutton (@marcysutton) from Substantial discuss the lack of focus in product development today in building accessible applications & services. Many times web accessibility becomes an afterthought in creating a software product, having little prioritization from the business side until it is a problem. Retrofitting such an important part of our development can make web accessibility seem more like a chore with low ROI for the the time taken to implement it. It can be easy if developers know how to do it and hardly any work when it is successfully incorporated into a development process and it's valued at the business level.   With recent advances in the past few years in JavaScript MV* frameworks like Angular, React, & Ember we are seeing the need for web accessibility more and more. Heavy JavaScript applications tend to provide little or wrong functionality for things we take for granted like keyboard access. Examples on modifying these to better attend to user experience traditionally meant lots of overhead in development by forking the framework and updating it constantly. Based on the resources developers typically find in online searches & Roles the lack of good developer examples, WAI ARIA & even simple accessibility is easy to misunderstand.   Many newer client side frameworks focus on componentization of HTML elements. Angular Directives, Ember Components, React Classes and Web Components. Componentization gives developers a chance to build much faster and easier Web Accessibility using various tools like WAI ARIA roles at a much more focused & reusable level. What is the future of Web Accessibility with these technologies? Why are we so concerned about Web Accessibility?   References: https://github.com/marcysutton/accessibility-of-mvcs http://www.w3.org/TR/wai-aria/appendices#a_schemata https://www.youtube.com/watch?v=BgvDZZ8Ms8c https://www.youtube.com/watch?v=ZPsb-RR8SC0 http://w3c.github.io/aria-in-html/ https://www.youtube.com/watch?v=_IBiXfxhF-A http://www.polymer-project.org/articles/accessible-web-components.html http://marcysutton.com/target-corporate-website/ http://www.w3.org/TR/2013/WD-components-intro-20130606/#decorator-section http://www.paciellogroup.com/blog/ http://www.paciellogroup.com/resources/wat/ http://www.w3.org/WAI/intro/aria http://webaim.org/ https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA  

今回は、AccSellクリッピング掲載記事に関連して、JAWSとNVDAの最新版について、WAI-ARIAのlive regionについて話しています。 そして、次回のAccSell Meetup (7月26日開催予定) についてのお知らせもあります。 いつもと同じ収録現場でアクセルの3人がいつもどおり並んでいます。左からお行儀よく座っている中根、小さい盆踊り風のポーズのizuizu、「農家のお米」と書いてあるお米（大きさは2kgぐらいかなぁ）を持ってる植木 いつもよりちょっと長いオープニング・トークに続いて、AccSellクリッピングに掲載したJAWS日本語版とNVDAの最新版に関する記事を紹介しています。JAWS、NVDAそれぞれの最新版の新機能について、簡単に触れています。 続いて、NVDAが最新版でInternet Explorer上でのWAI-ARIA live regionに対応したということに関連して、WAI-ARIAとは、またlive regionとは何かということを簡単に紹介しています。 そして、ここでizuizuが担当する (かもしれない) 新企画が決定!! 最後に、7月26日に開催予定のAccSell Meetup 006について、現時点で決まっている内容をお知らせしています。 収録後記 今回のオープニングネタ、皆さん分かっていただけたでしょうか？　ネタ元はザ・チャンス！というテレビ番組です。動画があればと思って、YouTubeで検索してみたんですが、ちょっと見つかりませんでした...。でも、四十代以降の方なら、きっと覚えているハズです（笑） (植木 真） なんか新たな課題が出てきて焦っています。AccSellの読者の方・リスナーのみなさま、ぜひともお力添えをーーーー！！ (山本 和泉） 今回も取り上げたWAI-ARIA、実は最初に登場したときはあまり興味がありませんでした。本当に普及するのか半信半疑だったというのが大きな理由だったと思います。ところが、最近いろいろなスクリーン・リーダーが積極的に対応するようになってきていて、そしてこれを活用するコンテンツも増えてきています。逆にいえば、WAI-ARIAを使わなければアクセシビリティーを保てないような動的なコンテンツがそれだけ増えたということでもあるのですが、いずれにしても、もう「興味が無い」とか言っていられる状況ではないのは確かです。最初に出遅れた分を取り戻すべく、最近は折に触れてWAI-ARIAについて調べていますが、もっとちゃんと知っておかないといけないなあと感じることが多い昨今です。 (中根 雅文） AccSellクリッピングの関連記事 [ニュース] エクストラ、日本語版JAWS 15.0を5月28日に発売 [ニュース] NV Access、NVDA 2014.2をリリース

今回は、AccSellクリッピング掲載記事に関連して、Windows用のオープンソースのスクリーン・リーダー、NVDAの最新動向、WAI-ARIA、NTドコモのWebアクセシビリティー方針について話しています。続いて、植木、中根が参加したCSUN Conferenceについてあれこれと話しています。 インスタント味噌汁2種類とトランプ。お味噌汁は日本ではお馴染みの「マルコメ」なのですが、パッケージに「Green Onion MISO SOUP」と「TOFU MISO SOUP」と書いてあります。アメリカで売ってる味噌スープのようです。トランプは「UNITED」って書いてあります。飛行機会社のトランプのようです。 まず、AccSellクリッピング掲載記事に関連して、NVDA最新版の新機能を簡単に紹介しています。この中で、NVDAやJAWSを使ったことがない人にはあまりなじみがないNVDAの「ブラウズ・モード」について簡単に話しています。 (簡単すぎて分からないかもしれませんが……。) 続いて、先頃W3C勧告となったWAI-ARIA 1.0について、勧告になったことの意味などについて話しています。 そして、先頃公開されたNTTドコモのWebアクセシビリティー方針について、簡単に紹介しています。 AccSellクリッピング掲載記事の紹介に続いて、植木、中根の両名が参加したCSUN Conferenceについてあれこれと話しています。その中で触れた基調講演については、ビデオが公開されていますので、興味がある方はご覧ください。 (ページが開くとビデオの再生が始まります。基調講演はビデオ開始から10分程度に始まります。) なお、CSUN Conferenceについては、公開されているスライドやビデオをまとめたページが公開されていますので、併せて参考にしてください。 収録後記 というわけで、CSUNというカンファレンスに参加して、無事に帰国してまいりました。帰国して早々、目のかゆみ、鼻づまりに悩まされ始めております。どうやら、花粉症であることはもはや疑う余地がないようです･･･。そんなワタクシなのですが、実は来週また海外へ行ってきます。今度の行先は、韓国のソウル。The 11th W4A (Web for All) Conferenceというカンファレンスで、2日間開催されます。CSUNと比べると規模は小さいのですが、その内容についてはまたシェアさせていただきます！ （植木 真） 11年ぶりのCSUN、11年ぶりのアメリカ旅行で、はたして時差ぼけにどれだけ対応できるか大変不安だったわけですが、驚いたことに渡米時も帰国時も全く時差ぼけはありませんでした。特に行きは飛行機の中で自分でもびっくりするくらいよく眠ったのが良かったようです。 久しぶりに行ってみて痛感したのは、やはり世界中に同じような目的でがんばっている人が大勢いて、そういった人たちとのつながりを作る場としては最高のチャンスだということでした。以前は、数年に1度行って最新動向をつかめばそれで良いと思っていましたが、最近ではCSUNで出会った人たちとその後の交流を続けることが以前より容易になりましたので、実際に足を運んで人と出会うことの価値が以前とは比べものにならないくらい高くなっていると感じます。今年行ったらもうしばらくは行かなくていいか、と行く前は思っていましたが、今は来年も参加するための費用をどうやって捻出しようかと考え始めています。 そんなCSUNの様子が、ポッドキャストやメール・マガジンのレポートから少しでも皆さんに伝われば良いなと思っています。 （中根 雅文） 中根さん、植木さん、おかえりなさいー！！ご無事でなによりです！ そしてお土産ありがとうございますー。植木さんからはマルコメのお味噌汁（とお菓子！）、中根さんからは飛行機会社のトランプをいただきました。これらでアメリカに心を馳せます。 （山本 和泉） AccSellクリッピングの関連記事 [ニュース] NV Access、NVDA 2014.1をリリース [ニュース] NVDA日本語チーム、NVDA 2014.1jpをリリース [ニュース] WAI-ARIA 1.0がW3C勧告に [ニュース] NTTドコモがウェブアクセシビリティ方針を公開

今回は、AccSellクリッピング掲載記事に関連して、まずWAI-ARIAについて話しています。その後、現在開催中の冬季オリンピックに関連して、オリンピック関連Webサイトとアクセシビリティーの話をしています。そして、最後に次回AccSell Meetupの予告をしています。 いつも収録場所に利用している株式会社サービシンクさんのエントランスでパチリ。左に中根さん、右に敬礼している植木さん。二人とも防寒ばっちりです。 まず、先頃W3C勧告案になったWAI-ARIA 1.0に関連して、そもそもWAI-ARIAってどんなものなのか、という話をしています。また、W3Cの仕様策定のプロセスについても簡単に触れています。 続いて、現在開催されている冬季オリンピックに関連して、オリンピックの関連Webサイトとアクセシビリティーについて話しています。 ポッドキャストの中でも触れましたが、JOCのソチオリンピックのページのコンテンツについて、先週発行のメール・マガジンの「izuizuのアクセシビリティ100本ノック」でちょうど取り上げたばかりです。こちらで全文をお読みいただけますので、皆さんもご覧になってぜひコメントをお寄せください。 最後に、次回のAccSell Meetupについてお知らせしています。現時点では、4月22日 (火) の夜に都内で開催することしか決まっていませんが、詳細が決まり次第、このサイト上やポッドキャストでお知らせします。また、Facebookのイベント・ページでも、随時最新情報をお届けします。こちらで「参加」ボタンを押していただけると、最新情報が届きますので、参加を検討してくださっている方は、ぜひアクセスしてください。 (なお、Facebook上での「参加」はイベントへの参加申し込みではありません。実際にご参加いただける場合は、後日お知らせする参加申し込みフォームからの登録をお願いします。) 収録後記 先週末も記録的な大雪でしたが、皆さんのところは大丈夫でしたでしょうか？　積雪によって、数日経った今でもまだ各地で孤立してしまっているエリアもあるようです。ご無事をお祈りしております。そして、予報では今週もまた雪が降るかもしれないんだとか･･･。夏は記録的な暑さになり、冬は記録的な雪が降るという最近の気象ですが、一体どうなっているんでしょうかねえ。 そして、オリンピッコーもいよいよ終盤戦。最後までドラマを見届けたいと思います。がんばれ、ニッポン！ （植木 真） 雪ドーンと降ったり積もったりすると、いつも以上に空気が乾燥するので保湿が大変すぎます（乾燥肌）。でも、東京のど真ん中で降り積もった雪の上をキュッキュッって踏みしめながら歩くの楽しかったです。でも、次の日のお昼間に積もったままのシャーベット状の雪の上を歩かないとあかんかったので楽しくなくなりました。 （山本 和泉） ポッドキャストの中でもお話ししたように、少しだけ長野オリンピック・パラリンピックのWebサイトに関わったのですが、あれからすでに16年も経ってしまっているということに気づいて驚愕しています。2020年の東京のWebサイトはどうなるのでしょうね。もしまた関われる機会に恵まれたら、今度はけんかをせずにもっとちゃんと貢献できるように努力しようと思います。 それはそうと、オリンピックが開催されているソチの方が、どうも東京よりも暖かいらしい、という話を聞いてなんとも納得のいかない気分になっています。 （中根 雅文） AccSellクリッピングの関連記事 [ニュース] WAI-ARIA 1.0がW3C勧告案に

2013年最後の配信となる今回は、年末拡大号といった感じで、ゲストもいないのに前後編に分けてお送りします。 前編では、ここ1ヶ月程度の期間にAccSellクリッピングに掲載した記事を、一気に8本紹介しています。紹介記事に関連して、動画のアクセシビリティー、フィード・リーダーの活用、NVDA新バージョンの機能などといったことについても話しています。 後編では、2013年のアクセシビリティー重大ニュースについて、あれこれと話しています。後編も併せてお聴きください。 なお、収録後記は後編でお届けします。 中根さん、植木さん、izuizuのスリーショットです。 AccSellクリッピングの関連記事 [ニュース] コニカミノルタがウェブアクセシビリティ方針と試験結果を公開 [ニュース] Web広告研究会が「第1回Webグランプリ」の「浅川賞（アクセシビリティ）」グランプリを発表 [ニュース] スペインのサッカークラブ「FCバルセロナ」公式サイトがWCAG 2.0　レベルAAに準拠 [ニュース] NV Access、NVDA 2013.3をリリース [ニュース] NVDA日本語チーム、NVDA 2013.3jpをリリース [ニュース] エクストラ、点字PDAの新製品、ブレイルセンスオンハンド日本語版U2ミニを12月24日に発売 [ニュース] Android用Kindle、TalkBackに対応 [ニュース] WAI-ARIA 1.0 User Agent Implementation Guideが勧告候補に

今回は、AccSellクリッピングに、1月中、収録前までに掲載した記事についてあれこれ話しています。 韓国のWebアクセシビリティに関する法規制 HTML5のmain要素とスキップリンクとWAI-ARIA landmark などなどについてお送りします。 収録後記 今回お話しているWAI-ARIAのランドマーク。収録後に、キーボード操作ユーザー向けのFirefoxアドオンを見つけました。その名も「landmarks」。これをインストールすると、ランドマークを指定してあるウェブページでは、Nキーを押すと赤い矩形が表示されてランドマークを順に移動し、目的のランドマークでTabキーを押すと、そのランドマーク内にあるリンクに移動できます。お試しあれ！ （植木 真） 毎月、基本的には第1水曜日と第3水曜日にお届けしているポッドキャストですが、今月は第1水曜日が年始早々だったということもあって、第3、第5水曜日にお届けしました。来月からは通常営業に戻ってお送りします。というわけで、次回の配信は1週間後を予定しています。次回もぜひお聴きください。 (中根 雅文) 知らない間にAccSellのWebサイトが中根さんによってちょいちょいチューニングされていた事実が！追いつかねば！（ホームページ制作がお仕事です☆） （山本 和泉） AccSellクリッピングの関連記事 [ニュース] 豊川市（愛知県）がウェブサイトをリニューアルして、JIS X 8341-3:2010の等級 AAに準拠 [ニュース] W3CのHTMLワーキンググループが、main要素をHTML 5.1のEditor's Draftに追加 [ニュース] 造幣局がウェブサイトをリニューアルして、JIS X 8341-3:2010の等級 AAに準拠

Where does WAI-ARIA fit into the HTML5 accessibility story? How can WAI-ARIA fill the gaps in HTML5 UI accessibility? More info at: https://fronteers.nl/congres/2010/sessions/html5-accessibility-is-it-ready-yet-steve-faulkner-hans-hillen

Where does WAI-ARIA fit into the HTML5 accessibility story? How can WAI-ARIA fill the gaps in HTML5 UI accessibility? More info at: https://fronteers.nl/congres/2010/sessions/html5-accessibility-is-it-ready-yet-steve-faulkner-hans-hillen

Auf jeder Webseite sind sie zu finden: Formulare. In der vorherigen und dieser Technikwürze wollen Sylvia Egger, Sascha Postner und Daniel Jagszent das Thema von allen Seiten beleuchten. In dieser Folge geht es um barrierefreie Formulare, mit Einblicken in HTML5 und WAI-ARIA.

Auf fast jeder Webseite sind sie zu finden: Formulare. In dieser und der nächsten Technikwürze wollen Sylvia Egger, Sascha Postner und Daniel Jagszent das Thema von allen Seiten beleuchten. In dieser Folge ist der Entwurf eines Formulars dran, Gedanken zur Barrierefreiheit, HTML5 und WAI-ARIA folgen in der nächsten Episode.