Hi W3 Community, Inquiring how others test their web pages to meet Success Criterion 1.4.10 Reflow (Level AA). I tried zooming in a Chrome window on my large-screen monitor to 400%, a Chrome window on my laptop monitor to 400%, and used inspect to resize the window size to 320px wide. Unfortunately, all have produced different results. Looking to see if anyone can provide the most correct/proper way to test out a website in Chrome. Thanks for your help! Sabrina
Hi W3 Community, Inquiring how others test their web pages to meet Success Criterion 1.4.10 Reflow (Level AA). I tried zooming in a Chrome window on my large-screen monitor to 400%, a Chrome window on my laptop monitor to 400%, and used inspect to resize the window size to 320px wide. Unfortunately, all have produced different results. Looking to see if anyone can provide the most correct/proper way to test out a website in Chrome. Thanks for your help! Sabrina
Hi W3 Community, Inquiring how others test their web pages to meet Success Criterion 1.4.10 Reflow (Level AA). I tried zooming in a Chrome window on my large-screen monitor to 400%, a Chrome window on my laptop monitor to 400%, and used inspect to resize the window size to 320px wide. Unfortunately, all have produced different results. Looking to see if anyone can provide the most correct/proper way to test out a website in Chrome. Thanks for your help! Sabrina
Hi W3 Community, Inquiring how others test their web pages to meet Success Criterion 1.4.10 Reflow (Level AA). I tried zooming in a Chrome window on my large-screen monitor to 400%, a Chrome window on my laptop monitor to 400%, and used inspect to resize the window size to 320px wide. Unfortunately, all have produced different results. Looking to see if anyone can provide the most correct/proper way to test out a website in Chrome. Thanks for your help! Sabrina
Hi W3 Community, Inquiring how others test their web pages to meet Success Criterion 1.4.10 Reflow (Level AA). I tried zooming in a Chrome window on my large-screen monitor to 400%, a Chrome window on my laptop monitor to 400%, and used inspect to resize the window size to 320px wide. Unfortunately, all have produced different results. Looking to see if anyone can provide the most correct/proper way to test out a website in Chrome. Thanks for your help! Sabrina
Hello W3 Community, I am part of a project that is trying to achieve Level AA WCAG compliance and has complex UI's including large data tables, embedded PDFs, and a scrollable timeline (similar to https://www.tiki-toki.com/). We did not start with mobile-first designs and are experiencing issues trying to meet the AA requirements (specifically *'SC 1.4.10 Reflow'*). Wondering if anyone has dealt with trying to fit a complex UI in a screen equivalent to 320px wide or can provide some web examples? Looking forward to your feedback, Sabrina
Hello W3 Community, I am part of a project that is trying to achieve Level AA WCAG compliance and has complex UI's including large data tables, embedded PDFs, and a scrollable timeline (similar to https://www.tiki-toki.com/). We did not start with mobile-first designs and are experiencing issues trying to meet the AA requirements (specifically *'SC 1.4.10 Reflow'*). Wondering if anyone has dealt with trying to fit a complex UI in a screen equivalent to 320px wide or can provide some web examples? Looking forward to your feedback, Sabrina
Hello W3 Community, I am part of a project that is trying to achieve Level AA WCAG compliance and has complex UI's including large data tables, embedded PDFs, and a scrollable timeline (similar to https://www.tiki-toki.com/). We did not start with mobile-first designs and are experiencing issues trying to meet the AA requirements (specifically *'SC 1.4.10 Reflow'*). Wondering if anyone has dealt with trying to fit a complex UI in a screen equivalent to 320px wide or can provide some web examples? Looking forward to your feedback, Sabrina
Hello W3 Community, I am part of a project that is trying to achieve Level AA WCAG compliance and has complex UI's including large data tables, embedded PDFs, and a scrollable timeline (similar to https://www.tiki-toki.com/). We did not start with mobile-first designs and are experiencing issues trying to meet the AA requirements (specifically *'SC 1.4.10 Reflow'*). Wondering if anyone has dealt with trying to fit a complex UI in a screen equivalent to 320px wide or can provide some web examples? Looking forward to your feedback, Sabrina
Hello W3 Community, I am part of a project that is trying to achieve Level AA WCAG compliance and has complex UI's including large data tables, embedded PDFs, and a scrollable timeline (similar to https://www.tiki-toki.com/). We did not start with mobile-first designs and are experiencing issues trying to meet the AA requirements (specifically *'SC 1.4.10 Reflow'*). Wondering if anyone has dealt with trying to fit a complex UI in a screen equivalent to 320px wide or can provide some web examples? Looking forward to your feedback, Sabrina
Disclosure - I'm sighted and look for logic not slavish adherence to a rule for the sake of it. Firstly my colleagues who use screenreaders say that skipped headings do cause them to be confused: is that because we, as an industry, have made the case too strongly that nesting must be seamless? Should we not be reflecting the relationships in the content not looking to plug apparent gaps. Take this example (which is an extension of the Webaim example on their page) H1: My Favorite Recipes H2: Quick and Easy H3: Spaghetti * Ingredients of spaghetti H3: Hamburgers H3: Tacos H4: Beef Tacos * Ingredients of Beef tacos H4: Chicken Tacos H4: Fish Tacos I would strongly argue that visually, logically and semantically both sets of ingredients should be the same heading level - they are the same thing. However, because there are sub-types of Taco the Taco ingredients drop to H5. As the semantics are supposed to convey relationships then surely spaghetti ingredients are also H5 irrespective of where the sit respective to Spaghetti? I'm genuinely looking to understand why grouping similar things is wrong purely to maintain a lack of gaps. Visually you would clearly not miss the H4 under Spaghetti because it's not needed - why is it so important for a screenreader? My reading also shows it's strong best practice but not, as far as I can tell, a failure of 1.3.1. And the essence of 1.3.1 is to convey the relationships shown visually (and visually all the ingredients are peers. Sorry - really would like to hear the consensus on how this should be marked up and why? Kevin Kevin Prince Product Accessibility & Usability Consultant E kevin.prince@fostermoore.com Christchurch fostermoore.com This email and its contents are confidential. If you are not the intended recipient, you should contact the sender immediately, you must not use, copy or disclose any of the information in the email, and you must delete it from your system immediately.
Disclosure - I'm sighted and look for logic not slavish adherence to a rule for the sake of it. Firstly my colleagues who use screenreaders say that skipped headings do cause them to be confused: is that because we, as an industry, have made the case too strongly that nesting must be seamless? Should we not be reflecting the relationships in the content not looking to plug apparent gaps. Take this example (which is an extension of the Webaim example on their page) H1: My Favorite Recipes H2: Quick and Easy H3: Spaghetti * Ingredients of spaghetti H3: Hamburgers H3: Tacos H4: Beef Tacos * Ingredients of Beef tacos H4: Chicken Tacos H4: Fish Tacos I would strongly argue that visually, logically and semantically both sets of ingredients should be the same heading level - they are the same thing. However, because there are sub-types of Taco the Taco ingredients drop to H5. As the semantics are supposed to convey relationships then surely spaghetti ingredients are also H5 irrespective of where the sit respective to Spaghetti? I'm genuinely looking to understand why grouping similar things is wrong purely to maintain a lack of gaps. Visually you would clearly not miss the H4 under Spaghetti because it's not needed - why is it so important for a screenreader? My reading also shows it's strong best practice but not, as far as I can tell, a failure of 1.3.1. And the essence of 1.3.1 is to convey the relationships shown visually (and visually all the ingredients are peers. Sorry - really would like to hear the consensus on how this should be marked up and why? Kevin Kevin Prince Product Accessibility & Usability Consultant E kevin.prince@fostermoore.com Christchurch fostermoore.com This email and its contents are confidential. If you are not the intended recipient, you should contact the sender immediately, you must not use, copy or disclose any of the information in the email, and you must delete it from your system immediately.
Disclosure - I'm sighted and look for logic not slavish adherence to a rule for the sake of it. Firstly my colleagues who use screenreaders say that skipped headings do cause them to be confused: is that because we, as an industry, have made the case too strongly that nesting must be seamless? Should we not be reflecting the relationships in the content not looking to plug apparent gaps. Take this example (which is an extension of the Webaim example on their page) H1: My Favorite Recipes H2: Quick and Easy H3: Spaghetti * Ingredients of spaghetti H3: Hamburgers H3: Tacos H4: Beef Tacos * Ingredients of Beef tacos H4: Chicken Tacos H4: Fish Tacos I would strongly argue that visually, logically and semantically both sets of ingredients should be the same heading level - they are the same thing. However, because there are sub-types of Taco the Taco ingredients drop to H5. As the semantics are supposed to convey relationships then surely spaghetti ingredients are also H5 irrespective of where the sit respective to Spaghetti? I'm genuinely looking to understand why grouping similar things is wrong purely to maintain a lack of gaps. Visually you would clearly not miss the H4 under Spaghetti because it's not needed - why is it so important for a screenreader? My reading also shows it's strong best practice but not, as far as I can tell, a failure of 1.3.1. And the essence of 1.3.1 is to convey the relationships shown visually (and visually all the ingredients are peers. Sorry - really would like to hear the consensus on how this should be marked up and why? Kevin Kevin Prince Product Accessibility & Usability Consultant E kevin.prince@fostermoore.com Christchurch fostermoore.com This email and its contents are confidential. If you are not the intended recipient, you should contact the sender immediately, you must not use, copy or disclose any of the information in the email, and you must delete it from your system immediately.
Disclosure - I'm sighted and look for logic not slavish adherence to a rule for the sake of it. Firstly my colleagues who use screenreaders say that skipped headings do cause them to be confused: is that because we, as an industry, have made the case too strongly that nesting must be seamless? Should we not be reflecting the relationships in the content not looking to plug apparent gaps. Take this example (which is an extension of the Webaim example on their page) H1: My Favorite Recipes H2: Quick and Easy H3: Spaghetti * Ingredients of spaghetti H3: Hamburgers H3: Tacos H4: Beef Tacos * Ingredients of Beef tacos H4: Chicken Tacos H4: Fish Tacos I would strongly argue that visually, logically and semantically both sets of ingredients should be the same heading level - they are the same thing. However, because there are sub-types of Taco the Taco ingredients drop to H5. As the semantics are supposed to convey relationships then surely spaghetti ingredients are also H5 irrespective of where the sit respective to Spaghetti? I'm genuinely looking to understand why grouping similar things is wrong purely to maintain a lack of gaps. Visually you would clearly not miss the H4 under Spaghetti because it's not needed - why is it so important for a screenreader? My reading also shows it's strong best practice but not, as far as I can tell, a failure of 1.3.1. And the essence of 1.3.1 is to convey the relationships shown visually (and visually all the ingredients are peers. Sorry - really would like to hear the consensus on how this should be marked up and why? Kevin Kevin Prince Product Accessibility & Usability Consultant E kevin.prince@fostermoore.com Christchurch fostermoore.com This email and its contents are confidential. If you are not the intended recipient, you should contact the sender immediately, you must not use, copy or disclose any of the information in the email, and you must delete it from your system immediately.
Disclosure - I'm sighted and look for logic not slavish adherence to a rule for the sake of it. Firstly my colleagues who use screenreaders say that skipped headings do cause them to be confused: is that because we, as an industry, have made the case too strongly that nesting must be seamless? Should we not be reflecting the relationships in the content not looking to plug apparent gaps. Take this example (which is an extension of the Webaim example on their page) H1: My Favorite Recipes H2: Quick and Easy H3: Spaghetti * Ingredients of spaghetti H3: Hamburgers H3: Tacos H4: Beef Tacos * Ingredients of Beef tacos H4: Chicken Tacos H4: Fish Tacos I would strongly argue that visually, logically and semantically both sets of ingredients should be the same heading level - they are the same thing. However, because there are sub-types of Taco the Taco ingredients drop to H5. As the semantics are supposed to convey relationships then surely spaghetti ingredients are also H5 irrespective of where the sit respective to Spaghetti? I'm genuinely looking to understand why grouping similar things is wrong purely to maintain a lack of gaps. Visually you would clearly not miss the H4 under Spaghetti because it's not needed - why is it so important for a screenreader? My reading also shows it's strong best practice but not, as far as I can tell, a failure of 1.3.1. And the essence of 1.3.1 is to convey the relationships shown visually (and visually all the ingredients are peers. Sorry - really would like to hear the consensus on how this should be marked up and why? Kevin Kevin Prince Product Accessibility & Usability Consultant E kevin.prince@fostermoore.com Christchurch fostermoore.com This email and its contents are confidential. If you are not the intended recipient, you should contact the sender immediately, you must not use, copy or disclose any of the information in the email, and you must delete it from your system immediately.
Disclosure - I'm sighted and look for logic not slavish adherence to a rule for the sake of it. Firstly my colleagues who use screenreaders say that skipped headings do cause them to be confused: is that because we, as an industry, have made the case too strongly that nesting must be seamless? Should we not be reflecting the relationships in the content not looking to plug apparent gaps. Take this example (which is an extension of the Webaim example on their page) H1: My Favorite Recipes H2: Quick and Easy H3: Spaghetti * Ingredients of spaghetti H3: Hamburgers H3: Tacos H4: Beef Tacos * Ingredients of Beef tacos H4: Chicken Tacos H4: Fish Tacos I would strongly argue that visually, logically and semantically both sets of ingredients should be the same heading level - they are the same thing. However, because there are sub-types of Taco the Taco ingredients drop to H5. As the semantics are supposed to convey relationships then surely spaghetti ingredients are also H5 irrespective of where the sit respective to Spaghetti? I'm genuinely looking to understand why grouping similar things is wrong purely to maintain a lack of gaps. Visually you would clearly not miss the H4 under Spaghetti because it's not needed - why is it so important for a screenreader? My reading also shows it's strong best practice but not, as far as I can tell, a failure of 1.3.1. And the essence of 1.3.1 is to convey the relationships shown visually (and visually all the ingredients are peers. Sorry - really would like to hear the consensus on how this should be marked up and why? Kevin Kevin Prince Product Accessibility & Usability Consultant E kevin.prince@fostermoore.com Christchurch fostermoore.com This email and its contents are confidential. If you are not the intended recipient, you should contact the sender immediately, you must not use, copy or disclose any of the information in the email, and you must delete it from your system immediately.
Disclosure - I'm sighted and look for logic not slavish adherence to a rule for the sake of it. Firstly my colleagues who use screenreaders say that skipped headings do cause them to be confused: is that because we, as an industry, have made the case too strongly that nesting must be seamless? Should we not be reflecting the relationships in the content not looking to plug apparent gaps. Take this example (which is an extension of the Webaim example on their page) H1: My Favorite Recipes H2: Quick and Easy H3: Spaghetti * Ingredients of spaghetti H3: Hamburgers H3: Tacos H4: Beef Tacos * Ingredients of Beef tacos H4: Chicken Tacos H4: Fish Tacos I would strongly argue that visually, logically and semantically both sets of ingredients should be the same heading level - they are the same thing. However, because there are sub-types of Taco the Taco ingredients drop to H5. As the semantics are supposed to convey relationships then surely spaghetti ingredients are also H5 irrespective of where the sit respective to Spaghetti? I'm genuinely looking to understand why grouping similar things is wrong purely to maintain a lack of gaps. Visually you would clearly not miss the H4 under Spaghetti because it's not needed - why is it so important for a screenreader? My reading also shows it's strong best practice but not, as far as I can tell, a failure of 1.3.1. And the essence of 1.3.1 is to convey the relationships shown visually (and visually all the ingredients are peers. Sorry - really would like to hear the consensus on how this should be marked up and why? Kevin Kevin Prince Product Accessibility & Usability Consultant E kevin.prince@fostermoore.com Christchurch fostermoore.com This email and its contents are confidential. If you are not the intended recipient, you should contact the sender immediately, you must not use, copy or disclose any of the information in the email, and you must delete it from your system immediately.
Disclosure - I'm sighted and look for logic not slavish adherence to a rule for the sake of it. Firstly my colleagues who use screenreaders say that skipped headings do cause them to be confused: is that because we, as an industry, have made the case too strongly that nesting must be seamless? Should we not be reflecting the relationships in the content not looking to plug apparent gaps. Take this example (which is an extension of the Webaim example on their page) H1: My Favorite Recipes H2: Quick and Easy H3: Spaghetti * Ingredients of spaghetti H3: Hamburgers H3: Tacos H4: Beef Tacos * Ingredients of Beef tacos H4: Chicken Tacos H4: Fish Tacos I would strongly argue that visually, logically and semantically both sets of ingredients should be the same heading level - they are the same thing. However, because there are sub-types of Taco the Taco ingredients drop to H5. As the semantics are supposed to convey relationships then surely spaghetti ingredients are also H5 irrespective of where the sit respective to Spaghetti? I'm genuinely looking to understand why grouping similar things is wrong purely to maintain a lack of gaps. Visually you would clearly not miss the H4 under Spaghetti because it's not needed - why is it so important for a screenreader? My reading also shows it's strong best practice but not, as far as I can tell, a failure of 1.3.1. And the essence of 1.3.1 is to convey the relationships shown visually (and visually all the ingredients are peers. Sorry - really would like to hear the consensus on how this should be marked up and why? Kevin Kevin Prince Product Accessibility & Usability Consultant E kevin.prince@fostermoore.com Christchurch fostermoore.com This email and its contents are confidential. If you are not the intended recipient, you should contact the sender immediately, you must not use, copy or disclose any of the information in the email, and you must delete it from your system immediately.
Disclosure - I'm sighted and look for logic not slavish adherence to a rule for the sake of it. Firstly my colleagues who use screenreaders say that skipped headings do cause them to be confused: is that because we, as an industry, have made the case too strongly that nesting must be seamless? Should we not be reflecting the relationships in the content not looking to plug apparent gaps. Take this example (which is an extension of the Webaim example on their page) H1: My Favorite Recipes H2: Quick and Easy H3: Spaghetti * Ingredients of spaghetti H3: Hamburgers H3: Tacos H4: Beef Tacos * Ingredients of Beef tacos H4: Chicken Tacos H4: Fish Tacos I would strongly argue that visually, logically and semantically both sets of ingredients should be the same heading level - they are the same thing. However, because there are sub-types of Taco the Taco ingredients drop to H5. As the semantics are supposed to convey relationships then surely spaghetti ingredients are also H5 irrespective of where the sit respective to Spaghetti? I'm genuinely looking to understand why grouping similar things is wrong purely to maintain a lack of gaps. Visually you would clearly not miss the H4 under Spaghetti because it's not needed - why is it so important for a screenreader? My reading also shows it's strong best practice but not, as far as I can tell, a failure of 1.3.1. And the essence of 1.3.1 is to convey the relationships shown visually (and visually all the ingredients are peers. Sorry - really would like to hear the consensus on how this should be marked up and why? Kevin Kevin Prince Product Accessibility & Usability Consultant E kevin.prince@fostermoore.com Christchurch fostermoore.com This email and its contents are confidential. If you are not the intended recipient, you should contact the sender immediately, you must not use, copy or disclose any of the information in the email, and you must delete it from your system immediately.
Disclosure - I'm sighted and look for logic not slavish adherence to a rule for the sake of it. Firstly my colleagues who use screenreaders say that skipped headings do cause them to be confused: is that because we, as an industry, have made the case too strongly that nesting must be seamless? Should we not be reflecting the relationships in the content not looking to plug apparent gaps. Take this example (which is an extension of the Webaim example on their page) H1: My Favorite Recipes H2: Quick and Easy H3: Spaghetti * Ingredients of spaghetti H3: Hamburgers H3: Tacos H4: Beef Tacos * Ingredients of Beef tacos H4: Chicken Tacos H4: Fish Tacos I would strongly argue that visually, logically and semantically both sets of ingredients should be the same heading level - they are the same thing. However, because there are sub-types of Taco the Taco ingredients drop to H5. As the semantics are supposed to convey relationships then surely spaghetti ingredients are also H5 irrespective of where the sit respective to Spaghetti? I'm genuinely looking to understand why grouping similar things is wrong purely to maintain a lack of gaps. Visually you would clearly not miss the H4 under Spaghetti because it's not needed - why is it so important for a screenreader? My reading also shows it's strong best practice but not, as far as I can tell, a failure of 1.3.1. And the essence of 1.3.1 is to convey the relationships shown visually (and visually all the ingredients are peers. Sorry - really would like to hear the consensus on how this should be marked up and why? Kevin Kevin Prince Product Accessibility & Usability Consultant E kevin.prince@fostermoore.com Christchurch fostermoore.com This email and its contents are confidential. If you are not the intended recipient, you should contact the sender immediately, you must not use, copy or disclose any of the information in the email, and you must delete it from your system immediately.
Disclosure - I'm sighted and look for logic not slavish adherence to a rule for the sake of it. Firstly my colleagues who use screenreaders say that skipped headings do cause them to be confused: is that because we, as an industry, have made the case too strongly that nesting must be seamless? Should we not be reflecting the relationships in the content not looking to plug apparent gaps. Take this example (which is an extension of the Webaim example on their page) H1: My Favorite Recipes H2: Quick and Easy H3: Spaghetti * Ingredients of spaghetti H3: Hamburgers H3: Tacos H4: Beef Tacos * Ingredients of Beef tacos H4: Chicken Tacos H4: Fish Tacos I would strongly argue that visually, logically and semantically both sets of ingredients should be the same heading level - they are the same thing. However, because there are sub-types of Taco the Taco ingredients drop to H5. As the semantics are supposed to convey relationships then surely spaghetti ingredients are also H5 irrespective of where the sit respective to Spaghetti? I'm genuinely looking to understand why grouping similar things is wrong purely to maintain a lack of gaps. Visually you would clearly not miss the H4 under Spaghetti because it's not needed - why is it so important for a screenreader? My reading also shows it's strong best practice but not, as far as I can tell, a failure of 1.3.1. And the essence of 1.3.1 is to convey the relationships shown visually (and visually all the ingredients are peers. Sorry - really would like to hear the consensus on how this should be marked up and why? Kevin Kevin Prince Product Accessibility & Usability Consultant E kevin.prince@fostermoore.com Christchurch fostermoore.com This email and its contents are confidential. If you are not the intended recipient, you should contact the sender immediately, you must not use, copy or disclose any of the information in the email, and you must delete it from your system immediately.
Disclosure - I'm sighted and look for logic not slavish adherence to a rule for the sake of it. Firstly my colleagues who use screenreaders say that skipped headings do cause them to be confused: is that because we, as an industry, have made the case too strongly that nesting must be seamless? Should we not be reflecting the relationships in the content not looking to plug apparent gaps. Take this example (which is an extension of the Webaim example on their page) H1: My Favorite Recipes H2: Quick and Easy H3: Spaghetti * Ingredients of spaghetti H3: Hamburgers H3: Tacos H4: Beef Tacos * Ingredients of Beef tacos H4: Chicken Tacos H4: Fish Tacos I would strongly argue that visually, logically and semantically both sets of ingredients should be the same heading level - they are the same thing. However, because there are sub-types of Taco the Taco ingredients drop to H5. As the semantics are supposed to convey relationships then surely spaghetti ingredients are also H5 irrespective of where the sit respective to Spaghetti? I'm genuinely looking to understand why grouping similar things is wrong purely to maintain a lack of gaps. Visually you would clearly not miss the H4 under Spaghetti because it's not needed - why is it so important for a screenreader? My reading also shows it's strong best practice but not, as far as I can tell, a failure of 1.3.1. And the essence of 1.3.1 is to convey the relationships shown visually (and visually all the ingredients are peers. Sorry - really would like to hear the consensus on how this should be marked up and why? Kevin Kevin Prince Product Accessibility & Usability Consultant E kevin.prince@fostermoore.com Christchurch fostermoore.com This email and its contents are confidential. If you are not the intended recipient, you should contact the sender immediately, you must not use, copy or disclose any of the information in the email, and you must delete it from your system immediately.
(Please excuse the cross-posts) Access 44 sessions from the 2023 Accessing Higher Ground Main Conference<https://accessinghigherground.org/list-recorded-2023/> Provide Campus-wide Access to Recordings for $490<https://accessinghigherground.org/2023-post-conference-resources/#Group_Access> (30% early registration discount until March 22) ATHEN & AHEAD members receive an additional 15% discount<https://accessinghigherground.org/2023-post-conference-resources/#discounts-2> If you did not attend the 2023 Accessing Higher Ground conference, or you attended but did not purchase access to conference videos, you can now obtain access at a discounted rate until March 22. You can also purchase access<https://cvent.me/vrg2Bg> to the 2023 pre-conference workshops<https://accessinghigherground.org/pre-conference-recordings-2023/> and the prior year’s 2022 main conference recordings<https://accessinghigherground.org/list-recorded-2022/> at a discount. Highlights from this year’s recorded sessions: (titles link to session description) Main Conference • Authoring Stylish and Accessible Courses in Canvas<https://accessinghigherground.org/authoring-stylish-and-accessible-courses-in-canvas/>, Sonya Woods, Penn State • Simplifying Web Accessibility at Any Scale<https://accessinghigherground.org/simplifying-web-accessibility-at-any-scale-2/>, Jay Pope, Pope Tech • Legal Compliance in the Digital World<https://accessinghigherground.org/legal-compliance-in-the-digital-world/>, Brenda Nowicki, 3Play Media, Michele Landis, Allyant (previously Accessible360) • PDF Accessibility – When is Good, Good Enough?<https://accessinghigherground.org/pdf-accessibility-when-is-good-good-enough/> Christa Miller, Virginia Tech • The Accessible Math Roadmap<https://accessinghigherground.org/the-accessible-math-roadmap/>, Darrin Evans, North Carolina Community College System • The Princeton Approach: Designing and Sustaining an Effective Digital Accessibility Program<https://accessinghigherground.org/the-princeton-approach-designing-and-sustaining-an-effective-digital-accessibility-program/>, Mary Albert, Princeton University • Trending Tech Tools – 2022 Edition: What’s New, What’s Improved & What’s on the Horizon for AT & Accessibility Tools<https://accessinghigherground.org/trending-tech-tools-2022-edition-whats-new-whats-improved-whats-on-the-horizon-for-at-accessibility-tools/>, Rachel Kruzel, Texthelp Pre-Conference • Mobile accessibility for web sites and native apps<https://accessinghigherground.org/mobile-accessibility-for-web-sites-and-native-apps/>, Gian Wild, AccessibilityOz • Managing the build of an accessible web site<https://accessinghigherground.org/managing-the-build-of-an-accessible-web-site-2/>, Gian Wild, AccessibilityOz (And over 35 more<https://accessinghigherground.org/list-recorded-2023/>) View complete virtual agenda<https://accessinghigherground.org/accepted-virtual-sessions-ahg-2023/> or register now<https://cvent.me/vrg2Bg>.<https://cvent.me/vrg2Bg> Pricing: $240 for individuals who did not attend AHG 2023* $160 for individuals who attended AHG 2023* *(For ATHEN or AHEAD members, $204 and $136, respectively) Visit our conference site<https://accessinghigherground.org/2023-post-conference-resources/> for more information, including pricing<https://accessinghigherground.org/2023-post-conference-resources/#Video_Audio_Recording_Pricing>, or access the registration site<https://cvent.me/zrxDdV> to purchase these resources. More Information If you have any questions, contact Howard Kramer at 720-351-8668 or at the email below. e-mail: hkramer@ahead.org<mailto:hkramer@ahead.org> Conference URL: http://accessinghigherground.org/ Howard Kramer CU-Boulder 720-351-8668
(Please excuse the cross-posts) Access 44 sessions from the 2023 Accessing Higher Ground Main Conference<https://accessinghigherground.org/list-recorded-2023/> Provide Campus-wide Access to Recordings for $490<https://accessinghigherground.org/2023-post-conference-resources/#Group_Access> (30% early registration discount until March 22) ATHEN & AHEAD members receive an additional 15% discount<https://accessinghigherground.org/2023-post-conference-resources/#discounts-2> If you did not attend the 2023 Accessing Higher Ground conference, or you attended but did not purchase access to conference videos, you can now obtain access at a discounted rate until March 22. You can also purchase access<https://cvent.me/vrg2Bg> to the 2023 pre-conference workshops<https://accessinghigherground.org/pre-conference-recordings-2023/> and the prior year’s 2022 main conference recordings<https://accessinghigherground.org/list-recorded-2022/> at a discount. Highlights from this year’s recorded sessions: (titles link to session description) Main Conference • Authoring Stylish and Accessible Courses in Canvas<https://accessinghigherground.org/authoring-stylish-and-accessible-courses-in-canvas/>, Sonya Woods, Penn State • Simplifying Web Accessibility at Any Scale<https://accessinghigherground.org/simplifying-web-accessibility-at-any-scale-2/>, Jay Pope, Pope Tech • Legal Compliance in the Digital World<https://accessinghigherground.org/legal-compliance-in-the-digital-world/>, Brenda Nowicki, 3Play Media, Michele Landis, Allyant (previously Accessible360) • PDF Accessibility – When is Good, Good Enough?<https://accessinghigherground.org/pdf-accessibility-when-is-good-good-enough/> Christa Miller, Virginia Tech • The Accessible Math Roadmap<https://accessinghigherground.org/the-accessible-math-roadmap/>, Darrin Evans, North Carolina Community College System • The Princeton Approach: Designing and Sustaining an Effective Digital Accessibility Program<https://accessinghigherground.org/the-princeton-approach-designing-and-sustaining-an-effective-digital-accessibility-program/>, Mary Albert, Princeton University • Trending Tech Tools – 2022 Edition: What’s New, What’s Improved & What’s on the Horizon for AT & Accessibility Tools<https://accessinghigherground.org/trending-tech-tools-2022-edition-whats-new-whats-improved-whats-on-the-horizon-for-at-accessibility-tools/>, Rachel Kruzel, Texthelp Pre-Conference • Mobile accessibility for web sites and native apps<https://accessinghigherground.org/mobile-accessibility-for-web-sites-and-native-apps/>, Gian Wild, AccessibilityOz • Managing the build of an accessible web site<https://accessinghigherground.org/managing-the-build-of-an-accessible-web-site-2/>, Gian Wild, AccessibilityOz (And over 35 more<https://accessinghigherground.org/list-recorded-2023/>) View complete virtual agenda<https://accessinghigherground.org/accepted-virtual-sessions-ahg-2023/> or register now<https://cvent.me/vrg2Bg>.<https://cvent.me/vrg2Bg> Pricing: $240 for individuals who did not attend AHG 2023* $160 for individuals who attended AHG 2023* *(For ATHEN or AHEAD members, $204 and $136, respectively) Visit our conference site<https://accessinghigherground.org/2023-post-conference-resources/> for more information, including pricing<https://accessinghigherground.org/2023-post-conference-resources/#Video_Audio_Recording_Pricing>, or access the registration site<https://cvent.me/zrxDdV> to purchase these resources. More Information If you have any questions, contact Howard Kramer at 720-351-8668 or at the email below. e-mail: hkramer@ahead.org<mailto:hkramer@ahead.org> Conference URL: http://accessinghigherground.org/ Howard Kramer CU-Boulder 720-351-8668
(Please excuse the cross-posts) Access 44 sessions from the 2023 Accessing Higher Ground Main Conference<https://accessinghigherground.org/list-recorded-2023/> Provide Campus-wide Access to Recordings for $490<https://accessinghigherground.org/2023-post-conference-resources/#Group_Access> (30% early registration discount until March 22) ATHEN & AHEAD members receive an additional 15% discount<https://accessinghigherground.org/2023-post-conference-resources/#discounts-2> If you did not attend the 2023 Accessing Higher Ground conference, or you attended but did not purchase access to conference videos, you can now obtain access at a discounted rate until March 22. You can also purchase access<https://cvent.me/vrg2Bg> to the 2023 pre-conference workshops<https://accessinghigherground.org/pre-conference-recordings-2023/> and the prior year’s 2022 main conference recordings<https://accessinghigherground.org/list-recorded-2022/> at a discount. Highlights from this year’s recorded sessions: (titles link to session description) Main Conference • Authoring Stylish and Accessible Courses in Canvas<https://accessinghigherground.org/authoring-stylish-and-accessible-courses-in-canvas/>, Sonya Woods, Penn State • Simplifying Web Accessibility at Any Scale<https://accessinghigherground.org/simplifying-web-accessibility-at-any-scale-2/>, Jay Pope, Pope Tech • Legal Compliance in the Digital World<https://accessinghigherground.org/legal-compliance-in-the-digital-world/>, Brenda Nowicki, 3Play Media, Michele Landis, Allyant (previously Accessible360) • PDF Accessibility – When is Good, Good Enough?<https://accessinghigherground.org/pdf-accessibility-when-is-good-good-enough/> Christa Miller, Virginia Tech • The Accessible Math Roadmap<https://accessinghigherground.org/the-accessible-math-roadmap/>, Darrin Evans, North Carolina Community College System • The Princeton Approach: Designing and Sustaining an Effective Digital Accessibility Program<https://accessinghigherground.org/the-princeton-approach-designing-and-sustaining-an-effective-digital-accessibility-program/>, Mary Albert, Princeton University • Trending Tech Tools – 2022 Edition: What’s New, What’s Improved & What’s on the Horizon for AT & Accessibility Tools<https://accessinghigherground.org/trending-tech-tools-2022-edition-whats-new-whats-improved-whats-on-the-horizon-for-at-accessibility-tools/>, Rachel Kruzel, Texthelp Pre-Conference • Mobile accessibility for web sites and native apps<https://accessinghigherground.org/mobile-accessibility-for-web-sites-and-native-apps/>, Gian Wild, AccessibilityOz • Managing the build of an accessible web site<https://accessinghigherground.org/managing-the-build-of-an-accessible-web-site-2/>, Gian Wild, AccessibilityOz (And over 35 more<https://accessinghigherground.org/list-recorded-2023/>) View complete virtual agenda<https://accessinghigherground.org/accepted-virtual-sessions-ahg-2023/> or register now<https://cvent.me/vrg2Bg>.<https://cvent.me/vrg2Bg> Pricing: $240 for individuals who did not attend AHG 2023* $160 for individuals who attended AHG 2023* *(For ATHEN or AHEAD members, $204 and $136, respectively) Visit our conference site<https://accessinghigherground.org/2023-post-conference-resources/> for more information, including pricing<https://accessinghigherground.org/2023-post-conference-resources/#Video_Audio_Recording_Pricing>, or access the registration site<https://cvent.me/zrxDdV> to purchase these resources. More Information If you have any questions, contact Howard Kramer at 720-351-8668 or at the email below. e-mail: hkramer@ahead.org<mailto:hkramer@ahead.org> Conference URL: http://accessinghigherground.org/ Howard Kramer CU-Boulder 720-351-8668
Regarding the WCAG 2.2 Technique F87: Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using ::before and ::after pseudo-elements and the 'content' property in CSS https://www.w3.org/WAI/WCAG22/Techniques/failures/F87 1. Does anyone agree that F87 is no longer a valid failure technique? * Quote: “A common way to test [this criterion]* is to disable CSS styles to view whether content added using pseudo-elements remains visible.” Who in 2024 disables CSS anymore (and why)? Disabling CSS and JavaScript is not a valid “disability” test in my opinion. * JAWS and free screen readers VoiceOver and NVDA support reading the content, including non-decorative content. * Quote: “…they may not be able to access the information that is inserted using CSS” is not explained why this is still valid even when users load their own CSS. If they load their own CSS, they are not disabling CSS & JavaScript. 2. Can anyone provide a web example where this “testing technique” would uncover a real accessibility problem? The text ”this critiera” is a typo on the W3C WAI page.
Regarding the WCAG 2.2 Technique F87: Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using ::before and ::after pseudo-elements and the 'content' property in CSS https://www.w3.org/WAI/WCAG22/Techniques/failures/F87 1. Does anyone agree that F87 is no longer a valid failure technique? * Quote: “A common way to test [this criterion]* is to disable CSS styles to view whether content added using pseudo-elements remains visible.” Who in 2024 disables CSS anymore (and why)? Disabling CSS and JavaScript is not a valid “disability” test in my opinion. * JAWS and free screen readers VoiceOver and NVDA support reading the content, including non-decorative content. * Quote: “…they may not be able to access the information that is inserted using CSS” is not explained why this is still valid even when users load their own CSS. If they load their own CSS, they are not disabling CSS & JavaScript. 2. Can anyone provide a web example where this “testing technique” would uncover a real accessibility problem? The text ”this critiera” is a typo on the W3C WAI page.
Regarding the WCAG 2.2 Technique F87: Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using ::before and ::after pseudo-elements and the 'content' property in CSS https://www.w3.org/WAI/WCAG22/Techniques/failures/F87 1. Does anyone agree that F87 is no longer a valid failure technique? * Quote: “A common way to test [this criterion]* is to disable CSS styles to view whether content added using pseudo-elements remains visible.” Who in 2024 disables CSS anymore (and why)? Disabling CSS and JavaScript is not a valid “disability” test in my opinion. * JAWS and free screen readers VoiceOver and NVDA support reading the content, including non-decorative content. * Quote: “…they may not be able to access the information that is inserted using CSS” is not explained why this is still valid even when users load their own CSS. If they load their own CSS, they are not disabling CSS & JavaScript. 2. Can anyone provide a web example where this “testing technique” would uncover a real accessibility problem? The text ”this critiera” is a typo on the W3C WAI page.
Regarding the WCAG 2.2 Technique F87: Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using ::before and ::after pseudo-elements and the 'content' property in CSS https://www.w3.org/WAI/WCAG22/Techniques/failures/F87 1. Does anyone agree that F87 is no longer a valid failure technique? * Quote: “A common way to test [this criterion]* is to disable CSS styles to view whether content added using pseudo-elements remains visible.” Who in 2024 disables CSS anymore (and why)? Disabling CSS and JavaScript is not a valid “disability” test in my opinion. * JAWS and free screen readers VoiceOver and NVDA support reading the content, including non-decorative content. * Quote: “…they may not be able to access the information that is inserted using CSS” is not explained why this is still valid even when users load their own CSS. If they load their own CSS, they are not disabling CSS & JavaScript. 2. Can anyone provide a web example where this “testing technique” would uncover a real accessibility problem? The text ”this critiera” is a typo on the W3C WAI page.
Regarding the WCAG 2.2 Technique F87: Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using ::before and ::after pseudo-elements and the 'content' property in CSS https://www.w3.org/WAI/WCAG22/Techniques/failures/F87 1. Does anyone agree that F87 is no longer a valid failure technique? * Quote: “A common way to test [this criterion]* is to disable CSS styles to view whether content added using pseudo-elements remains visible.” Who in 2024 disables CSS anymore (and why)? Disabling CSS and JavaScript is not a valid “disability” test in my opinion. * JAWS and free screen readers VoiceOver and NVDA support reading the content, including non-decorative content. * Quote: “…they may not be able to access the information that is inserted using CSS” is not explained why this is still valid even when users load their own CSS. If they load their own CSS, they are not disabling CSS & JavaScript. 2. Can anyone provide a web example where this “testing technique” would uncover a real accessibility problem? The text ”this critiera” is a typo on the W3C WAI page.
Regarding the WCAG 2.2 Technique F87: Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using ::before and ::after pseudo-elements and the 'content' property in CSS https://www.w3.org/WAI/WCAG22/Techniques/failures/F87 1. Does anyone agree that F87 is no longer a valid failure technique? * Quote: “A common way to test [this criterion]* is to disable CSS styles to view whether content added using pseudo-elements remains visible.” Who in 2024 disables CSS anymore (and why)? Disabling CSS and JavaScript is not a valid “disability” test in my opinion. * JAWS and free screen readers VoiceOver and NVDA support reading the content, including non-decorative content. * Quote: “…they may not be able to access the information that is inserted using CSS” is not explained why this is still valid even when users load their own CSS. If they load their own CSS, they are not disabling CSS & JavaScript. 2. Can anyone provide a web example where this “testing technique” would uncover a real accessibility problem? The text ”this critiera” is a typo on the W3C WAI page.
Regarding the WCAG 2.2 Technique F87: Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using ::before and ::after pseudo-elements and the 'content' property in CSS https://www.w3.org/WAI/WCAG22/Techniques/failures/F87 1. Does anyone agree that F87 is no longer a valid failure technique? * Quote: “A common way to test [this criterion]* is to disable CSS styles to view whether content added using pseudo-elements remains visible.” Who in 2024 disables CSS anymore (and why)? Disabling CSS and JavaScript is not a valid “disability” test in my opinion. * JAWS and free screen readers VoiceOver and NVDA support reading the content, including non-decorative content. * Quote: “…they may not be able to access the information that is inserted using CSS” is not explained why this is still valid even when users load their own CSS. If they load their own CSS, they are not disabling CSS & JavaScript. 2. Can anyone provide a web example where this “testing technique” would uncover a real accessibility problem? The text ”this critiera” is a typo on the W3C WAI page.
Regarding the WCAG 2.2 Technique F87: Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using ::before and ::after pseudo-elements and the 'content' property in CSS https://www.w3.org/WAI/WCAG22/Techniques/failures/F87 1. Does anyone agree that F87 is no longer a valid failure technique? * Quote: “A common way to test [this criterion]* is to disable CSS styles to view whether content added using pseudo-elements remains visible.” Who in 2024 disables CSS anymore (and why)? Disabling CSS and JavaScript is not a valid “disability” test in my opinion. * JAWS and free screen readers VoiceOver and NVDA support reading the content, including non-decorative content. * Quote: “…they may not be able to access the information that is inserted using CSS” is not explained why this is still valid even when users load their own CSS. If they load their own CSS, they are not disabling CSS & JavaScript. 2. Can anyone provide a web example where this “testing technique” would uncover a real accessibility problem? The text ”this critiera” is a typo on the W3C WAI page.
Regarding the WCAG 2.2 Technique F87: Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using ::before and ::after pseudo-elements and the 'content' property in CSS https://www.w3.org/WAI/WCAG22/Techniques/failures/F87 1. Does anyone agree that F87 is no longer a valid failure technique? * Quote: “A common way to test [this criterion]* is to disable CSS styles to view whether content added using pseudo-elements remains visible.” Who in 2024 disables CSS anymore (and why)? Disabling CSS and JavaScript is not a valid “disability” test in my opinion. * JAWS and free screen readers VoiceOver and NVDA support reading the content, including non-decorative content. * Quote: “…they may not be able to access the information that is inserted using CSS” is not explained why this is still valid even when users load their own CSS. If they load their own CSS, they are not disabling CSS & JavaScript. 2. Can anyone provide a web example where this “testing technique” would uncover a real accessibility problem? The text ”this critiera” is a typo on the W3C WAI page.
Regarding the WCAG 2.2 Technique F87: Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using ::before and ::after pseudo-elements and the 'content' property in CSS https://www.w3.org/WAI/WCAG22/Techniques/failures/F87 1. Does anyone agree that F87 is no longer a valid failure technique? * Quote: “A common way to test [this criterion]* is to disable CSS styles to view whether content added using pseudo-elements remains visible.” Who in 2024 disables CSS anymore (and why)? Disabling CSS and JavaScript is not a valid “disability” test in my opinion. * JAWS and free screen readers VoiceOver and NVDA support reading the content, including non-decorative content. * Quote: “…they may not be able to access the information that is inserted using CSS” is not explained why this is still valid even when users load their own CSS. If they load their own CSS, they are not disabling CSS & JavaScript. 2. Can anyone provide a web example where this “testing technique” would uncover a real accessibility problem? The text ”this critiera” is a typo on the W3C WAI page.
Regarding the WCAG 2.2 Technique F87: Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using ::before and ::after pseudo-elements and the 'content' property in CSS https://www.w3.org/WAI/WCAG22/Techniques/failures/F87 1. Does anyone agree that F87 is no longer a valid failure technique? * Quote: “A common way to test [this criterion]* is to disable CSS styles to view whether content added using pseudo-elements remains visible.” Who in 2024 disables CSS anymore (and why)? Disabling CSS and JavaScript is not a valid “disability” test in my opinion. * JAWS and free screen readers VoiceOver and NVDA support reading the content, including non-decorative content. * Quote: “…they may not be able to access the information that is inserted using CSS” is not explained why this is still valid even when users load their own CSS. If they load their own CSS, they are not disabling CSS & JavaScript. 2. Can anyone provide a web example where this “testing technique” would uncover a real accessibility problem? The text ”this critiera” is a typo on the W3C WAI page.
Regarding the WCAG 2.2 Technique F87: Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using ::before and ::after pseudo-elements and the 'content' property in CSS https://www.w3.org/WAI/WCAG22/Techniques/failures/F87 1. Does anyone agree that F87 is no longer a valid failure technique? * Quote: “A common way to test [this criterion]* is to disable CSS styles to view whether content added using pseudo-elements remains visible.” Who in 2024 disables CSS anymore (and why)? Disabling CSS and JavaScript is not a valid “disability” test in my opinion. * JAWS and free screen readers VoiceOver and NVDA support reading the content, including non-decorative content. * Quote: “…they may not be able to access the information that is inserted using CSS” is not explained why this is still valid even when users load their own CSS. If they load their own CSS, they are not disabling CSS & JavaScript. 2. Can anyone provide a web example where this “testing technique” would uncover a real accessibility problem? The text ”this critiera” is a typo on the W3C WAI page.
Regarding the WCAG 2.2 Technique F87: Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using ::before and ::after pseudo-elements and the 'content' property in CSS https://www.w3.org/WAI/WCAG22/Techniques/failures/F87 1. Does anyone agree that F87 is no longer a valid failure technique? * Quote: “A common way to test [this criterion]* is to disable CSS styles to view whether content added using pseudo-elements remains visible.” Who in 2024 disables CSS anymore (and why)? Disabling CSS and JavaScript is not a valid “disability” test in my opinion. * JAWS and free screen readers VoiceOver and NVDA support reading the content, including non-decorative content. * Quote: “…they may not be able to access the information that is inserted using CSS” is not explained why this is still valid even when users load their own CSS. If they load their own CSS, they are not disabling CSS & JavaScript. 2. Can anyone provide a web example where this “testing technique” would uncover a real accessibility problem? The text ”this critiera” is a typo on the W3C WAI page.
Regarding the WCAG 2.2 Technique F87: Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using ::before and ::after pseudo-elements and the 'content' property in CSS https://www.w3.org/WAI/WCAG22/Techniques/failures/F87 1. Does anyone agree that F87 is no longer a valid failure technique? * Quote: “A common way to test [this criterion]* is to disable CSS styles to view whether content added using pseudo-elements remains visible.” Who in 2024 disables CSS anymore (and why)? Disabling CSS and JavaScript is not a valid “disability” test in my opinion. * JAWS and free screen readers VoiceOver and NVDA support reading the content, including non-decorative content. * Quote: “…they may not be able to access the information that is inserted using CSS” is not explained why this is still valid even when users load their own CSS. If they load their own CSS, they are not disabling CSS & JavaScript. 2. Can anyone provide a web example where this “testing technique” would uncover a real accessibility problem? The text ”this critiera” is a typo on the W3C WAI page.
Regarding the WCAG 2.2 Technique F87: Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using ::before and ::after pseudo-elements and the 'content' property in CSS https://www.w3.org/WAI/WCAG22/Techniques/failures/F87 1. Does anyone agree that F87 is no longer a valid failure technique? * Quote: “A common way to test [this criterion]* is to disable CSS styles to view whether content added using pseudo-elements remains visible.” Who in 2024 disables CSS anymore (and why)? Disabling CSS and JavaScript is not a valid “disability” test in my opinion. * JAWS and free screen readers VoiceOver and NVDA support reading the content, including non-decorative content. * Quote: “…they may not be able to access the information that is inserted using CSS” is not explained why this is still valid even when users load their own CSS. If they load their own CSS, they are not disabling CSS & JavaScript. 2. Can anyone provide a web example where this “testing technique” would uncover a real accessibility problem? The text ”this critiera” is a typo on the W3C WAI page.
Regarding the WCAG 2.2 Technique F87: Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using ::before and ::after pseudo-elements and the 'content' property in CSS https://www.w3.org/WAI/WCAG22/Techniques/failures/F87 1. Does anyone agree that F87 is no longer a valid failure technique? * Quote: “A common way to test [this criterion]* is to disable CSS styles to view whether content added using pseudo-elements remains visible.” Who in 2024 disables CSS anymore (and why)? Disabling CSS and JavaScript is not a valid “disability” test in my opinion. * JAWS and free screen readers VoiceOver and NVDA support reading the content, including non-decorative content. * Quote: “…they may not be able to access the information that is inserted using CSS” is not explained why this is still valid even when users load their own CSS. If they load their own CSS, they are not disabling CSS & JavaScript. 2. Can anyone provide a web example where this “testing technique” would uncover a real accessibility problem? The text ”this critiera” is a typo on the W3C WAI page.
Regarding the WCAG 2.2 Technique F87: Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using ::before and ::after pseudo-elements and the 'content' property in CSS https://www.w3.org/WAI/WCAG22/Techniques/failures/F87 1. Does anyone agree that F87 is no longer a valid failure technique? * Quote: “A common way to test [this criterion]* is to disable CSS styles to view whether content added using pseudo-elements remains visible.” Who in 2024 disables CSS anymore (and why)? Disabling CSS and JavaScript is not a valid “disability” test in my opinion. * JAWS and free screen readers VoiceOver and NVDA support reading the content, including non-decorative content. * Quote: “…they may not be able to access the information that is inserted using CSS” is not explained why this is still valid even when users load their own CSS. If they load their own CSS, they are not disabling CSS & JavaScript. 2. Can anyone provide a web example where this “testing technique” would uncover a real accessibility problem? The text ”this critiera” is a typo on the W3C WAI page.
Regarding the WCAG 2.2 Technique F87: Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using ::before and ::after pseudo-elements and the 'content' property in CSS https://www.w3.org/WAI/WCAG22/Techniques/failures/F87 1. Does anyone agree that F87 is no longer a valid failure technique? * Quote: “A common way to test [this criterion]* is to disable CSS styles to view whether content added using pseudo-elements remains visible.” Who in 2024 disables CSS anymore (and why)? Disabling CSS and JavaScript is not a valid “disability” test in my opinion. * JAWS and free screen readers VoiceOver and NVDA support reading the content, including non-decorative content. * Quote: “…they may not be able to access the information that is inserted using CSS” is not explained why this is still valid even when users load their own CSS. If they load their own CSS, they are not disabling CSS & JavaScript. 2. Can anyone provide a web example where this “testing technique” would uncover a real accessibility problem? The text ”this critiera” is a typo on the W3C WAI page.
Regarding the WCAG 2.2 Technique F87: Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using ::before and ::after pseudo-elements and the 'content' property in CSS https://www.w3.org/WAI/WCAG22/Techniques/failures/F87 1. Does anyone agree that F87 is no longer a valid failure technique? * Quote: “A common way to test [this criterion]* is to disable CSS styles to view whether content added using pseudo-elements remains visible.” Who in 2024 disables CSS anymore (and why)? Disabling CSS and JavaScript is not a valid “disability” test in my opinion. * JAWS and free screen readers VoiceOver and NVDA support reading the content, including non-decorative content. * Quote: “…they may not be able to access the information that is inserted using CSS” is not explained why this is still valid even when users load their own CSS. If they load their own CSS, they are not disabling CSS & JavaScript. 2. Can anyone provide a web example where this “testing technique” would uncover a real accessibility problem? The text ”this critiera” is a typo on the W3C WAI page.
Regarding the WCAG 2.2 Technique F87: Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using ::before and ::after pseudo-elements and the 'content' property in CSS https://www.w3.org/WAI/WCAG22/Techniques/failures/F87 1. Does anyone agree that F87 is no longer a valid failure technique? * Quote: “A common way to test [this criterion]* is to disable CSS styles to view whether content added using pseudo-elements remains visible.” Who in 2024 disables CSS anymore (and why)? Disabling CSS and JavaScript is not a valid “disability” test in my opinion. * JAWS and free screen readers VoiceOver and NVDA support reading the content, including non-decorative content. * Quote: “…they may not be able to access the information that is inserted using CSS” is not explained why this is still valid even when users load their own CSS. If they load their own CSS, they are not disabling CSS & JavaScript. 2. Can anyone provide a web example where this “testing technique” would uncover a real accessibility problem? The text ”this critiera” is a typo on the W3C WAI page.
Regarding the WCAG 2.2 Technique F87: Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using ::before and ::after pseudo-elements and the 'content' property in CSS https://www.w3.org/WAI/WCAG22/Techniques/failures/F87 1. Does anyone agree that F87 is no longer a valid failure technique? * Quote: “A common way to test [this criterion]* is to disable CSS styles to view whether content added using pseudo-elements remains visible.” Who in 2024 disables CSS anymore (and why)? Disabling CSS and JavaScript is not a valid “disability” test in my opinion. * JAWS and free screen readers VoiceOver and NVDA support reading the content, including non-decorative content. * Quote: “…they may not be able to access the information that is inserted using CSS” is not explained why this is still valid even when users load their own CSS. If they load their own CSS, they are not disabling CSS & JavaScript. 2. Can anyone provide a web example where this “testing technique” would uncover a real accessibility problem? The text ”this critiera” is a typo on the W3C WAI page.
Regarding the WCAG 2.2 Technique F87: Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using ::before and ::after pseudo-elements and the 'content' property in CSS https://www.w3.org/WAI/WCAG22/Techniques/failures/F87 1. Does anyone agree that F87 is no longer a valid failure technique? * Quote: “A common way to test [this criterion]* is to disable CSS styles to view whether content added using pseudo-elements remains visible.” Who in 2024 disables CSS anymore (and why)? Disabling CSS and JavaScript is not a valid “disability” test in my opinion. * JAWS and free screen readers VoiceOver and NVDA support reading the content, including non-decorative content. * Quote: “…they may not be able to access the information that is inserted using CSS” is not explained why this is still valid even when users load their own CSS. If they load their own CSS, they are not disabling CSS & JavaScript. 2. Can anyone provide a web example where this “testing technique” would uncover a real accessibility problem? The text ”this critiera” is a typo on the W3C WAI page.
Regarding the WCAG 2.2 Technique F87: Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using ::before and ::after pseudo-elements and the 'content' property in CSS https://www.w3.org/WAI/WCAG22/Techniques/failures/F87 1. Does anyone agree that F87 is no longer a valid failure technique? * Quote: “A common way to test [this criterion]* is to disable CSS styles to view whether content added using pseudo-elements remains visible.” Who in 2024 disables CSS anymore (and why)? Disabling CSS and JavaScript is not a valid “disability” test in my opinion. * JAWS and free screen readers VoiceOver and NVDA support reading the content, including non-decorative content. * Quote: “…they may not be able to access the information that is inserted using CSS” is not explained why this is still valid even when users load their own CSS. If they load their own CSS, they are not disabling CSS & JavaScript. 2. Can anyone provide a web example where this “testing technique” would uncover a real accessibility problem? The text ”this critiera” is a typo on the W3C WAI page.
Regarding the WCAG 2.2 Technique F87: Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using ::before and ::after pseudo-elements and the 'content' property in CSS https://www.w3.org/WAI/WCAG22/Techniques/failures/F87 1. Does anyone agree that F87 is no longer a valid failure technique? * Quote: “A common way to test [this criterion]* is to disable CSS styles to view whether content added using pseudo-elements remains visible.” Who in 2024 disables CSS anymore (and why)? Disabling CSS and JavaScript is not a valid “disability” test in my opinion. * JAWS and free screen readers VoiceOver and NVDA support reading the content, including non-decorative content. * Quote: “…they may not be able to access the information that is inserted using CSS” is not explained why this is still valid even when users load their own CSS. If they load their own CSS, they are not disabling CSS & JavaScript. 2. Can anyone provide a web example where this “testing technique” would uncover a real accessibility problem? The text ”this critiera” is a typo on the W3C WAI page.
Hi, I'm looking for mobile applications to demonstrate accessibility components. I already know 2 of such applications, but they are no longer maintained. These are : * mDAN : https://github.com/Orange-OpenSource/m-dan * Deque Uni for Android : https://github.com/dequelabs/Deque-University-for-Android These apps are still very useful and usable, but some accessibility API updates are missing. Do you know of any similar apps? Ideally available on stores with open code, but I'm open to any alternative. Also, if you have applications that you know fully compliant (or close to it), I'd be interested in extanding my list. Thanks in advance ! Regards, Margot -- Margot Keller mkeller@atalan.fr ------------------------------------------------------------------------ *Atalan*, accessibilité numérique et sensibilisation au handicap Nous recrutons /!/ <https://www.accede-web.com/recrutement-accessibilite-numerique/> Atalan est coordinateur des projets AcceDe Web <http://www.accede-web.com> et AcceDe PDF <http://www.pdf-accessible.com>
Hi, I'm looking for mobile applications to demonstrate accessibility components. I already know 2 of such applications, but they are no longer maintained. These are : * mDAN : https://github.com/Orange-OpenSource/m-dan * Deque Uni for Android : https://github.com/dequelabs/Deque-University-for-Android These apps are still very useful and usable, but some accessibility API updates are missing. Do you know of any similar apps? Ideally available on stores with open code, but I'm open to any alternative. Also, if you have applications that you know fully compliant (or close to it), I'd be interested in extanding my list. Thanks in advance ! Regards, Margot -- Margot Keller mkeller@atalan.fr ------------------------------------------------------------------------ *Atalan*, accessibilité numérique et sensibilisation au handicap Nous recrutons /!/ <https://www.accede-web.com/recrutement-accessibilite-numerique/> Atalan est coordinateur des projets AcceDe Web <http://www.accede-web.com> et AcceDe PDF <http://www.pdf-accessible.com>
Hi, I'm looking for mobile applications to demonstrate accessibility components. I already know 2 of such applications, but they are no longer maintained. These are : * mDAN : https://github.com/Orange-OpenSource/m-dan * Deque Uni for Android : https://github.com/dequelabs/Deque-University-for-Android These apps are still very useful and usable, but some accessibility API updates are missing. Do you know of any similar apps? Ideally available on stores with open code, but I'm open to any alternative. Also, if you have applications that you know fully compliant (or close to it), I'd be interested in extanding my list. Thanks in advance ! Regards, Margot -- Margot Keller mkeller@atalan.fr ------------------------------------------------------------------------ *Atalan*, accessibilité numérique et sensibilisation au handicap Nous recrutons /!/ <https://www.accede-web.com/recrutement-accessibilite-numerique/> Atalan est coordinateur des projets AcceDe Web <http://www.accede-web.com> et AcceDe PDF <http://www.pdf-accessible.com>
Hi, I'm looking for mobile applications to demonstrate accessibility components. I already know 2 of such applications, but they are no longer maintained. These are : * mDAN : https://github.com/Orange-OpenSource/m-dan * Deque Uni for Android : https://github.com/dequelabs/Deque-University-for-Android These apps are still very useful and usable, but some accessibility API updates are missing. Do you know of any similar apps? Ideally available on stores with open code, but I'm open to any alternative. Also, if you have applications that you know fully compliant (or close to it), I'd be interested in extanding my list. Thanks in advance ! Regards, Margot -- Margot Keller mkeller@atalan.fr ------------------------------------------------------------------------ *Atalan*, accessibilité numérique et sensibilisation au handicap Nous recrutons /!/ <https://www.accede-web.com/recrutement-accessibilite-numerique/> Atalan est coordinateur des projets AcceDe Web <http://www.accede-web.com> et AcceDe PDF <http://www.pdf-accessible.com>
Hi, I'm looking for mobile applications to demonstrate accessibility components. I already know 2 of such applications, but they are no longer maintained. These are : * mDAN : https://github.com/Orange-OpenSource/m-dan * Deque Uni for Android : https://github.com/dequelabs/Deque-University-for-Android These apps are still very useful and usable, but some accessibility API updates are missing. Do you know of any similar apps? Ideally available on stores with open code, but I'm open to any alternative. Also, if you have applications that you know fully compliant (or close to it), I'd be interested in extanding my list. Thanks in advance ! Regards, Margot -- Margot Keller mkeller@atalan.fr ------------------------------------------------------------------------ *Atalan*, accessibilité numérique et sensibilisation au handicap Nous recrutons /!/ <https://www.accede-web.com/recrutement-accessibilite-numerique/> Atalan est coordinateur des projets AcceDe Web <http://www.accede-web.com> et AcceDe PDF <http://www.pdf-accessible.com>
Hi, I'm looking for mobile applications to demonstrate accessibility components. I already know 2 of such applications, but they are no longer maintained. These are : * mDAN : https://github.com/Orange-OpenSource/m-dan * Deque Uni for Android : https://github.com/dequelabs/Deque-University-for-Android These apps are still very useful and usable, but some accessibility API updates are missing. Do you know of any similar apps? Ideally available on stores with open code, but I'm open to any alternative. Also, if you have applications that you know fully compliant (or close to it), I'd be interested in extanding my list. Thanks in advance ! Regards, Margot -- Margot Keller mkeller@atalan.fr ------------------------------------------------------------------------ *Atalan*, accessibilité numérique et sensibilisation au handicap Nous recrutons /!/ <https://www.accede-web.com/recrutement-accessibilite-numerique/> Atalan est coordinateur des projets AcceDe Web <http://www.accede-web.com> et AcceDe PDF <http://www.pdf-accessible.com>
Hi, I'm looking for mobile applications to demonstrate accessibility components. I already know 2 of such applications, but they are no longer maintained. These are : * mDAN : https://github.com/Orange-OpenSource/m-dan * Deque Uni for Android : https://github.com/dequelabs/Deque-University-for-Android These apps are still very useful and usable, but some accessibility API updates are missing. Do you know of any similar apps? Ideally available on stores with open code, but I'm open to any alternative. Also, if you have applications that you know fully compliant (or close to it), I'd be interested in extanding my list. Thanks in advance ! Regards, Margot -- Margot Keller mkeller@atalan.fr ------------------------------------------------------------------------ *Atalan*, accessibilité numérique et sensibilisation au handicap Nous recrutons /!/ <https://www.accede-web.com/recrutement-accessibilite-numerique/> Atalan est coordinateur des projets AcceDe Web <http://www.accede-web.com> et AcceDe PDF <http://www.pdf-accessible.com>
Hi, I'm looking for mobile applications to demonstrate accessibility components. I already know 2 of such applications, but they are no longer maintained. These are : * mDAN : https://github.com/Orange-OpenSource/m-dan * Deque Uni for Android : https://github.com/dequelabs/Deque-University-for-Android These apps are still very useful and usable, but some accessibility API updates are missing. Do you know of any similar apps? Ideally available on stores with open code, but I'm open to any alternative. Also, if you have applications that you know fully compliant (or close to it), I'd be interested in extanding my list. Thanks in advance ! Regards, Margot -- Margot Keller mkeller@atalan.fr ------------------------------------------------------------------------ *Atalan*, accessibilité numérique et sensibilisation au handicap Nous recrutons /!/ <https://www.accede-web.com/recrutement-accessibilite-numerique/> Atalan est coordinateur des projets AcceDe Web <http://www.accede-web.com> et AcceDe PDF <http://www.pdf-accessible.com>
Hi, I'm looking for mobile applications to demonstrate accessibility components. I already know 2 of such applications, but they are no longer maintained. These are : * mDAN : https://github.com/Orange-OpenSource/m-dan * Deque Uni for Android : https://github.com/dequelabs/Deque-University-for-Android These apps are still very useful and usable, but some accessibility API updates are missing. Do you know of any similar apps? Ideally available on stores with open code, but I'm open to any alternative. Also, if you have applications that you know fully compliant (or close to it), I'd be interested in extanding my list. Thanks in advance ! Regards, Margot -- Margot Keller mkeller@atalan.fr ------------------------------------------------------------------------ *Atalan*, accessibilité numérique et sensibilisation au handicap Nous recrutons /!/ <https://www.accede-web.com/recrutement-accessibilite-numerique/> Atalan est coordinateur des projets AcceDe Web <http://www.accede-web.com> et AcceDe PDF <http://www.pdf-accessible.com>
Hi, I'm looking for mobile applications to demonstrate accessibility components. I already know 2 of such applications, but they are no longer maintained. These are : * mDAN : https://github.com/Orange-OpenSource/m-dan * Deque Uni for Android : https://github.com/dequelabs/Deque-University-for-Android These apps are still very useful and usable, but some accessibility API updates are missing. Do you know of any similar apps? Ideally available on stores with open code, but I'm open to any alternative. Also, if you have applications that you know fully compliant (or close to it), I'd be interested in extanding my list. Thanks in advance ! Regards, Margot -- Margot Keller mkeller@atalan.fr ------------------------------------------------------------------------ *Atalan*, accessibilité numérique et sensibilisation au handicap Nous recrutons /!/ <https://www.accede-web.com/recrutement-accessibilite-numerique/> Atalan est coordinateur des projets AcceDe Web <http://www.accede-web.com> et AcceDe PDF <http://www.pdf-accessible.com>
Hi, I'm looking for mobile applications to demonstrate accessibility components. I already know 2 of such applications, but they are no longer maintained. These are : * mDAN : https://github.com/Orange-OpenSource/m-dan * Deque Uni for Android : https://github.com/dequelabs/Deque-University-for-Android These apps are still very useful and usable, but some accessibility API updates are missing. Do you know of any similar apps? Ideally available on stores with open code, but I'm open to any alternative. Also, if you have applications that you know fully compliant (or close to it), I'd be interested in extanding my list. Thanks in advance ! Regards, Margot -- Margot Keller mkeller@atalan.fr ------------------------------------------------------------------------ *Atalan*, accessibilité numérique et sensibilisation au handicap Nous recrutons /!/ <https://www.accede-web.com/recrutement-accessibilite-numerique/> Atalan est coordinateur des projets AcceDe Web <http://www.accede-web.com> et AcceDe PDF <http://www.pdf-accessible.com>
Hi, I'm looking for mobile applications to demonstrate accessibility components. I already know 2 of such applications, but they are no longer maintained. These are : * mDAN : https://github.com/Orange-OpenSource/m-dan * Deque Uni for Android : https://github.com/dequelabs/Deque-University-for-Android These apps are still very useful and usable, but some accessibility API updates are missing. Do you know of any similar apps? Ideally available on stores with open code, but I'm open to any alternative. Also, if you have applications that you know fully compliant (or close to it), I'd be interested in extanding my list. Thanks in advance ! Regards, Margot -- Margot Keller mkeller@atalan.fr ------------------------------------------------------------------------ *Atalan*, accessibilité numérique et sensibilisation au handicap Nous recrutons /!/ <https://www.accede-web.com/recrutement-accessibilite-numerique/> Atalan est coordinateur des projets AcceDe Web <http://www.accede-web.com> et AcceDe PDF <http://www.pdf-accessible.com>
Hi, I'm looking for mobile applications to demonstrate accessibility components. I already know 2 of such applications, but they are no longer maintained. These are : * mDAN : https://github.com/Orange-OpenSource/m-dan * Deque Uni for Android : https://github.com/dequelabs/Deque-University-for-Android These apps are still very useful and usable, but some accessibility API updates are missing. Do you know of any similar apps? Ideally available on stores with open code, but I'm open to any alternative. Also, if you have applications that you know fully compliant (or close to it), I'd be interested in extanding my list. Thanks in advance ! Regards, Margot -- Margot Keller mkeller@atalan.fr ------------------------------------------------------------------------ *Atalan*, accessibilité numérique et sensibilisation au handicap Nous recrutons /!/ <https://www.accede-web.com/recrutement-accessibilite-numerique/> Atalan est coordinateur des projets AcceDe Web <http://www.accede-web.com> et AcceDe PDF <http://www.pdf-accessible.com>
Hi, I'm looking for mobile applications to demonstrate accessibility components. I already know 2 of such applications, but they are no longer maintained. These are : * mDAN : https://github.com/Orange-OpenSource/m-dan * Deque Uni for Android : https://github.com/dequelabs/Deque-University-for-Android These apps are still very useful and usable, but some accessibility API updates are missing. Do you know of any similar apps? Ideally available on stores with open code, but I'm open to any alternative. Also, if you have applications that you know fully compliant (or close to it), I'd be interested in extanding my list. Thanks in advance ! Regards, Margot -- Margot Keller mkeller@atalan.fr ------------------------------------------------------------------------ *Atalan*, accessibilité numérique et sensibilisation au handicap Nous recrutons /!/ <https://www.accede-web.com/recrutement-accessibilite-numerique/> Atalan est coordinateur des projets AcceDe Web <http://www.accede-web.com> et AcceDe PDF <http://www.pdf-accessible.com>
Hi there. I have a very long GOV.UK process with lots of pages. The first page I activate the skip to content link and it works as expected, however, for the rest of the hjourney users are now automatically taken to the main content everytime because the anchor in the URL #main-content' is always there. So it often skips the h1, hint text, back link etc....therefore I'd say affecting SR and KO users. I understand this is a potentially a backend mistake but I still feel this falls under 2.4.3 Focus Order? Is this right? Thank you.
Hi there. I have a very long GOV.UK process with lots of pages. The first page I activate the skip to content link and it works as expected, however, for the rest of the hjourney users are now automatically taken to the main content everytime because the anchor in the URL #main-content' is always there. So it often skips the h1, hint text, back link etc....therefore I'd say affecting SR and KO users. I understand this is a potentially a backend mistake but I still feel this falls under 2.4.3 Focus Order? Is this right? Thank you.
Hi there. I have a very long GOV.UK process with lots of pages. The first page I activate the skip to content link and it works as expected, however, for the rest of the hjourney users are now automatically taken to the main content everytime because the anchor in the URL #main-content' is always there. So it often skips the h1, hint text, back link etc....therefore I'd say affecting SR and KO users. I understand this is a potentially a backend mistake but I still feel this falls under 2.4.3 Focus Order? Is this right? Thank you.
Hi there. I have a very long GOV.UK process with lots of pages. The first page I activate the skip to content link and it works as expected, however, for the rest of the hjourney users are now automatically taken to the main content everytime because the anchor in the URL #main-content' is always there. So it often skips the h1, hint text, back link etc....therefore I'd say affecting SR and KO users. I understand this is a potentially a backend mistake but I still feel this falls under 2.4.3 Focus Order? Is this right? Thank you.
Hi there. I have a very long GOV.UK process with lots of pages. The first page I activate the skip to content link and it works as expected, however, for the rest of the hjourney users are now automatically taken to the main content everytime because the anchor in the URL #main-content' is always there. So it often skips the h1, hint text, back link etc....therefore I'd say affecting SR and KO users. I understand this is a potentially a backend mistake but I still feel this falls under 2.4.3 Focus Order? Is this right? Thank you.
Hi there. I have a very long GOV.UK process with lots of pages. The first page I activate the skip to content link and it works as expected, however, for the rest of the hjourney users are now automatically taken to the main content everytime because the anchor in the URL #main-content' is always there. So it often skips the h1, hint text, back link etc....therefore I'd say affecting SR and KO users. I understand this is a potentially a backend mistake but I still feel this falls under 2.4.3 Focus Order? Is this right? Thank you.
Hi there. I have a very long GOV.UK process with lots of pages. The first page I activate the skip to content link and it works as expected, however, for the rest of the hjourney users are now automatically taken to the main content everytime because the anchor in the URL #main-content' is always there. So it often skips the h1, hint text, back link etc....therefore I'd say affecting SR and KO users. I understand this is a potentially a backend mistake but I still feel this falls under 2.4.3 Focus Order? Is this right? Thank you.
Hi there. I have a very long GOV.UK process with lots of pages. The first page I activate the skip to content link and it works as expected, however, for the rest of the hjourney users are now automatically taken to the main content everytime because the anchor in the URL #main-content' is always there. So it often skips the h1, hint text, back link etc....therefore I'd say affecting SR and KO users. I understand this is a potentially a backend mistake but I still feel this falls under 2.4.3 Focus Order? Is this right? Thank you.
Hi there. I have a very long GOV.UK process with lots of pages. The first page I activate the skip to content link and it works as expected, however, for the rest of the hjourney users are now automatically taken to the main content everytime because the anchor in the URL #main-content' is always there. So it often skips the h1, hint text, back link etc....therefore I'd say affecting SR and KO users. I understand this is a potentially a backend mistake but I still feel this falls under 2.4.3 Focus Order? Is this right? Thank you.
Hi there. I have a very long GOV.UK process with lots of pages. The first page I activate the skip to content link and it works as expected, however, for the rest of the hjourney users are now automatically taken to the main content everytime because the anchor in the URL #main-content' is always there. So it often skips the h1, hint text, back link etc....therefore I'd say affecting SR and KO users. I understand this is a potentially a backend mistake but I still feel this falls under 2.4.3 Focus Order? Is this right? Thank you.
Hi there. I have a very long GOV.UK process with lots of pages. The first page I activate the skip to content link and it works as expected, however, for the rest of the hjourney users are now automatically taken to the main content everytime because the anchor in the URL #main-content' is always there. So it often skips the h1, hint text, back link etc....therefore I'd say affecting SR and KO users. I understand this is a potentially a backend mistake but I still feel this falls under 2.4.3 Focus Order? Is this right? Thank you.
Hi there. I have a very long GOV.UK process with lots of pages. The first page I activate the skip to content link and it works as expected, however, for the rest of the hjourney users are now automatically taken to the main content everytime because the anchor in the URL #main-content' is always there. So it often skips the h1, hint text, back link etc....therefore I'd say affecting SR and KO users. I understand this is a potentially a backend mistake but I still feel this falls under 2.4.3 Focus Order? Is this right? Thank you.
Hi there. I have a very long GOV.UK process with lots of pages. The first page I activate the skip to content link and it works as expected, however, for the rest of the hjourney users are now automatically taken to the main content everytime because the anchor in the URL #main-content' is always there. So it often skips the h1, hint text, back link etc....therefore I'd say affecting SR and KO users. I understand this is a potentially a backend mistake but I still feel this falls under 2.4.3 Focus Order? Is this right? Thank you.
Hi there. I have a very long GOV.UK process with lots of pages. The first page I activate the skip to content link and it works as expected, however, for the rest of the hjourney users are now automatically taken to the main content everytime because the anchor in the URL #main-content' is always there. So it often skips the h1, hint text, back link etc....therefore I'd say affecting SR and KO users. I understand this is a potentially a backend mistake but I still feel this falls under 2.4.3 Focus Order? Is this right? Thank you.
Hi there. I have a very long GOV.UK process with lots of pages. The first page I activate the skip to content link and it works as expected, however, for the rest of the hjourney users are now automatically taken to the main content everytime because the anchor in the URL #main-content' is always there. So it often skips the h1, hint text, back link etc....therefore I'd say affecting SR and KO users. I understand this is a potentially a backend mistake but I still feel this falls under 2.4.3 Focus Order? Is this right? Thank you.
Hi there. I have a very long GOV.UK process with lots of pages. The first page I activate the skip to content link and it works as expected, however, for the rest of the hjourney users are now automatically taken to the main content everytime because the anchor in the URL #main-content' is always there. So it often skips the h1, hint text, back link etc....therefore I'd say affecting SR and KO users. I understand this is a potentially a backend mistake but I still feel this falls under 2.4.3 Focus Order? Is this right? Thank you.
Hi there. I have a very long GOV.UK process with lots of pages. The first page I activate the skip to content link and it works as expected, however, for the rest of the hjourney users are now automatically taken to the main content everytime because the anchor in the URL #main-content' is always there. So it often skips the h1, hint text, back link etc....therefore I'd say affecting SR and KO users. I understand this is a potentially a backend mistake but I still feel this falls under 2.4.3 Focus Order? Is this right? Thank you.
Hi there. I have a very long GOV.UK process with lots of pages. The first page I activate the skip to content link and it works as expected, however, for the rest of the hjourney users are now automatically taken to the main content everytime because the anchor in the URL #main-content' is always there. So it often skips the h1, hint text, back link etc....therefore I'd say affecting SR and KO users. I understand this is a potentially a backend mistake but I still feel this falls under 2.4.3 Focus Order? Is this right? Thank you.
Hi there. I have a very long GOV.UK process with lots of pages. The first page I activate the skip to content link and it works as expected, however, for the rest of the hjourney users are now automatically taken to the main content everytime because the anchor in the URL #main-content' is always there. So it often skips the h1, hint text, back link etc....therefore I'd say affecting SR and KO users. I understand this is a potentially a backend mistake but I still feel this falls under 2.4.3 Focus Order? Is this right? Thank you.
Hi there. I have a very long GOV.UK process with lots of pages. The first page I activate the skip to content link and it works as expected, however, for the rest of the hjourney users are now automatically taken to the main content everytime because the anchor in the URL #main-content' is always there. So it often skips the h1, hint text, back link etc....therefore I'd say affecting SR and KO users. I understand this is a potentially a backend mistake but I still feel this falls under 2.4.3 Focus Order? Is this right? Thank you.
Hi there. I have a very long GOV.UK process with lots of pages. The first page I activate the skip to content link and it works as expected, however, for the rest of the hjourney users are now automatically taken to the main content everytime because the anchor in the URL #main-content' is always there. So it often skips the h1, hint text, back link etc....therefore I'd say affecting SR and KO users. I understand this is a potentially a backend mistake but I still feel this falls under 2.4.3 Focus Order? Is this right? Thank you.
Hi there. I have a very long GOV.UK process with lots of pages. The first page I activate the skip to content link and it works as expected, however, for the rest of the hjourney users are now automatically taken to the main content everytime because the anchor in the URL #main-content' is always there. So it often skips the h1, hint text, back link etc....therefore I'd say affecting SR and KO users. I understand this is a potentially a backend mistake but I still feel this falls under 2.4.3 Focus Order? Is this right? Thank you.
Hi, If a TABLE is used for layout, and it includes role="presentation", and it does *not* include th, summary, caption, header, scope, and it makes sense when linearized; given the HTML spec says, in (I am surprised and happy to find) unequivocal language: "Tables MUST not be used as layout aids." (https://html.spec.whatwg.org/#the-table-element) (my emphasis) am I OK to WCAG fail it? I assume since the demise of 4.1.1 I am not able to fail TABLEs used in this way ::sadFace:: Thanks in advance for confirmations or surprises. Regards, Alan . . . . - . . - - - Alan Bristow ( he / him / il ) Web Developer / Développeur Web Elections Canada / Élections Canada alan.bristow@elections.ca<mailto:alan.bristow@elections.ca>
Hi, If a TABLE is used for layout, and it includes role="presentation", and it does *not* include th, summary, caption, header, scope, and it makes sense when linearized; given the HTML spec says, in (I am surprised and happy to find) unequivocal language: "Tables MUST not be used as layout aids." (https://html.spec.whatwg.org/#the-table-element) (my emphasis) am I OK to WCAG fail it? I assume since the demise of 4.1.1 I am not able to fail TABLEs used in this way ::sadFace:: Thanks in advance for confirmations or surprises. Regards, Alan . . . . - . . - - - Alan Bristow ( he / him / il ) Web Developer / Développeur Web Elections Canada / Élections Canada alan.bristow@elections.ca<mailto:alan.bristow@elections.ca>
Hi, If a TABLE is used for layout, and it includes role="presentation", and it does *not* include th, summary, caption, header, scope, and it makes sense when linearized; given the HTML spec says, in (I am surprised and happy to find) unequivocal language: "Tables MUST not be used as layout aids." (https://html.spec.whatwg.org/#the-table-element) (my emphasis) am I OK to WCAG fail it? I assume since the demise of 4.1.1 I am not able to fail TABLEs used in this way ::sadFace:: Thanks in advance for confirmations or surprises. Regards, Alan . . . . - . . - - - Alan Bristow ( he / him / il ) Web Developer / Développeur Web Elections Canada / Élections Canada alan.bristow@elections.ca<mailto:alan.bristow@elections.ca>
Hi, If a TABLE is used for layout, and it includes role="presentation", and it does *not* include th, summary, caption, header, scope, and it makes sense when linearized; given the HTML spec says, in (I am surprised and happy to find) unequivocal language: "Tables MUST not be used as layout aids." (https://html.spec.whatwg.org/#the-table-element) (my emphasis) am I OK to WCAG fail it? I assume since the demise of 4.1.1 I am not able to fail TABLEs used in this way ::sadFace:: Thanks in advance for confirmations or surprises. Regards, Alan . . . . - . . - - - Alan Bristow ( he / him / il ) Web Developer / Développeur Web Elections Canada / Élections Canada alan.bristow@elections.ca<mailto:alan.bristow@elections.ca>
Hi there WAI team, Can you help us with this? See thread. ---------- Forwarded message ---------- From: Denis Ah-Kang <denis@w3.org> Date: 28 Feb 2024 at 15.59 +0100 To: Oliver Odgaard <olod@mapspeople.com> Subject: Re: W3C Recommendations Pointer Question > Sorry, I didn't understand you were looking for answers related to > accessibility. I would suggest to write an email to the WAI Interest > Group at w3c-wai-ig@w3.org (archives at [1]). They should be able > to provide a more accurate answer than me :) > > You may also find some resources on their website [2]. > > Regards, > > Denis > > [1] https://lists.w3.org/Archives/Public/w3c-wai-ig/ > [2] https://www.w3.org/WAI/ > > > > On 28/02/2024 18:37, Oliver Odgaard wrote: > > Hi Denis, thanks for the super fast reply. So that means, from reading > > the links you sent, we can still be WCAG 2.1 AA compliant if we use a > > pointer on clickable elements? Is that correct? > > > > -- > > > > > > Kind regards, > > > > *Oliver Odgaard* > > Lead Product Designer > > > > <https://www.mapspeople.com/> > > e. olod@mapspeople.com <mailto:olod@mapspeople.com> > > > > w. mapspeople.com <http://mapspeople.com/> > > > > > > <https://www.linkedin.com/company/mapspeople/> > > <https://www.facebook.com/mapspeople> > > <https://twitter.com/mapspeople?lang=en> > > <https://www.youtube.com/c/MapsPeople/videos> > > > > On 28. feb. 2024 15.19 +0100, Denis Ah-Kang <denis@w3.org>, wrote: > > > Hi Oliver, > > > > > > I'm guessing you are referring to [1] but that issue was actually > > > discussed [2] and the newest version of the spec has the pointer cursor > > > indicating an interactive element [3]. > > > So there's no problem using a pointer on clickable elements. > > > > > > HTH, > > > > > > Denis > > > > > > > > > [1] https://www.w3.org/TR/CSS21/ui.html#cursor-props > > > [2] https://github.com/w3c/csswg-drafts/issues/1936 > > > [3] https://www.w3.org/TR/css-ui-3/#cursor > > > > > > > > > > > > On 28/02/2024 08:50, Oliver Odgaard wrote: > > > > Hi Denis, > > > > > > > > Can you help me regarding use of a pointer on our web application? > > > > > > > > The W3C recommendations says to use a pointer on "The cursor is a > > > > pointer that indicates a link.", but if we choose to use a pointer on > > > > clickable elements like buttons (that aren't links) and interactive > > > > elements inside our product, will that mean we can't say we are not W3C > > > > compliant? > > > > > > > > We would love the added affordance that the pointer adds, making > > > > interactive elements clearly recognizable and usable for all users. > > > > > > > > -- > > > > > > > > > > > > Kind regards, > > > > > > > > *Oliver Odgaard* > > > > Lead Product Designer > > > > > > > > <https://www.mapspeople.com/> > > > > e. olod@mapspeople.com <mailto:olod@mapspeople.com> > > > > > > > > w. mapspeople.com <http://mapspeople.com/> > > > > > > > > > > > > <https://www.linkedin.com/company/mapspeople/> > > > > <https://www.facebook.com/mapspeople> > > > > <https://twitter.com/mapspeople?lang=en> > > > > <https://www.youtube.com/c/MapsPeople/videos> > > > >
Hi there WAI team, Can you help us with this? See thread. ---------- Forwarded message ---------- From: Denis Ah-Kang <denis@w3.org> Date: 28 Feb 2024 at 15.59 +0100 To: Oliver Odgaard <olod@mapspeople.com> Subject: Re: W3C Recommendations Pointer Question > Sorry, I didn't understand you were looking for answers related to > accessibility. I would suggest to write an email to the WAI Interest > Group at w3c-wai-ig@w3.org (archives at [1]). They should be able > to provide a more accurate answer than me :) > > You may also find some resources on their website [2]. > > Regards, > > Denis > > [1] https://lists.w3.org/Archives/Public/w3c-wai-ig/ > [2] https://www.w3.org/WAI/ > > > > On 28/02/2024 18:37, Oliver Odgaard wrote: > > Hi Denis, thanks for the super fast reply. So that means, from reading > > the links you sent, we can still be WCAG 2.1 AA compliant if we use a > > pointer on clickable elements? Is that correct? > > > > -- > > > > > > Kind regards, > > > > *Oliver Odgaard* > > Lead Product Designer > > > > <https://www.mapspeople.com/> > > e. olod@mapspeople.com <mailto:olod@mapspeople.com> > > > > w. mapspeople.com <http://mapspeople.com/> > > > > > > <https://www.linkedin.com/company/mapspeople/> > > <https://www.facebook.com/mapspeople> > > <https://twitter.com/mapspeople?lang=en> > > <https://www.youtube.com/c/MapsPeople/videos> > > > > On 28. feb. 2024 15.19 +0100, Denis Ah-Kang <denis@w3.org>, wrote: > > > Hi Oliver, > > > > > > I'm guessing you are referring to [1] but that issue was actually > > > discussed [2] and the newest version of the spec has the pointer cursor > > > indicating an interactive element [3]. > > > So there's no problem using a pointer on clickable elements. > > > > > > HTH, > > > > > > Denis > > > > > > > > > [1] https://www.w3.org/TR/CSS21/ui.html#cursor-props > > > [2] https://github.com/w3c/csswg-drafts/issues/1936 > > > [3] https://www.w3.org/TR/css-ui-3/#cursor > > > > > > > > > > > > On 28/02/2024 08:50, Oliver Odgaard wrote: > > > > Hi Denis, > > > > > > > > Can you help me regarding use of a pointer on our web application? > > > > > > > > The W3C recommendations says to use a pointer on "The cursor is a > > > > pointer that indicates a link.", but if we choose to use a pointer on > > > > clickable elements like buttons (that aren't links) and interactive > > > > elements inside our product, will that mean we can't say we are not W3C > > > > compliant? > > > > > > > > We would love the added affordance that the pointer adds, making > > > > interactive elements clearly recognizable and usable for all users. > > > > > > > > -- > > > > > > > > > > > > Kind regards, > > > > > > > > *Oliver Odgaard* > > > > Lead Product Designer > > > > > > > > <https://www.mapspeople.com/> > > > > e. olod@mapspeople.com <mailto:olod@mapspeople.com> > > > > > > > > w. mapspeople.com <http://mapspeople.com/> > > > > > > > > > > > > <https://www.linkedin.com/company/mapspeople/> > > > > <https://www.facebook.com/mapspeople> > > > > <https://twitter.com/mapspeople?lang=en> > > > > <https://www.youtube.com/c/MapsPeople/videos> > > > >
Hi there WAI team, Can you help us with this? See thread. ---------- Forwarded message ---------- From: Denis Ah-Kang <denis@w3.org> Date: 28 Feb 2024 at 15.59 +0100 To: Oliver Odgaard <olod@mapspeople.com> Subject: Re: W3C Recommendations Pointer Question > Sorry, I didn't understand you were looking for answers related to > accessibility. I would suggest to write an email to the WAI Interest > Group at w3c-wai-ig@w3.org (archives at [1]). They should be able > to provide a more accurate answer than me :) > > You may also find some resources on their website [2]. > > Regards, > > Denis > > [1] https://lists.w3.org/Archives/Public/w3c-wai-ig/ > [2] https://www.w3.org/WAI/ > > > > On 28/02/2024 18:37, Oliver Odgaard wrote: > > Hi Denis, thanks for the super fast reply. So that means, from reading > > the links you sent, we can still be WCAG 2.1 AA compliant if we use a > > pointer on clickable elements? Is that correct? > > > > -- > > > > > > Kind regards, > > > > *Oliver Odgaard* > > Lead Product Designer > > > > <https://www.mapspeople.com/> > > e. olod@mapspeople.com <mailto:olod@mapspeople.com> > > > > w. mapspeople.com <http://mapspeople.com/> > > > > > > <https://www.linkedin.com/company/mapspeople/> > > <https://www.facebook.com/mapspeople> > > <https://twitter.com/mapspeople?lang=en> > > <https://www.youtube.com/c/MapsPeople/videos> > > > > On 28. feb. 2024 15.19 +0100, Denis Ah-Kang <denis@w3.org>, wrote: > > > Hi Oliver, > > > > > > I'm guessing you are referring to [1] but that issue was actually > > > discussed [2] and the newest version of the spec has the pointer cursor > > > indicating an interactive element [3]. > > > So there's no problem using a pointer on clickable elements. > > > > > > HTH, > > > > > > Denis > > > > > > > > > [1] https://www.w3.org/TR/CSS21/ui.html#cursor-props > > > [2] https://github.com/w3c/csswg-drafts/issues/1936 > > > [3] https://www.w3.org/TR/css-ui-3/#cursor > > > > > > > > > > > > On 28/02/2024 08:50, Oliver Odgaard wrote: > > > > Hi Denis, > > > > > > > > Can you help me regarding use of a pointer on our web application? > > > > > > > > The W3C recommendations says to use a pointer on "The cursor is a > > > > pointer that indicates a link.", but if we choose to use a pointer on > > > > clickable elements like buttons (that aren't links) and interactive > > > > elements inside our product, will that mean we can't say we are not W3C > > > > compliant? > > > > > > > > We would love the added affordance that the pointer adds, making > > > > interactive elements clearly recognizable and usable for all users. > > > > > > > > -- > > > > > > > > > > > > Kind regards, > > > > > > > > *Oliver Odgaard* > > > > Lead Product Designer > > > > > > > > <https://www.mapspeople.com/> > > > > e. olod@mapspeople.com <mailto:olod@mapspeople.com> > > > > > > > > w. mapspeople.com <http://mapspeople.com/> > > > > > > > > > > > > <https://www.linkedin.com/company/mapspeople/> > > > > <https://www.facebook.com/mapspeople> > > > > <https://twitter.com/mapspeople?lang=en> > > > > <https://www.youtube.com/c/MapsPeople/videos> > > > >
Hi there WAI team, Can you help us with this? See thread. ---------- Forwarded message ---------- From: Denis Ah-Kang <denis@w3.org> Date: 28 Feb 2024 at 15.59 +0100 To: Oliver Odgaard <olod@mapspeople.com> Subject: Re: W3C Recommendations Pointer Question > Sorry, I didn't understand you were looking for answers related to > accessibility. I would suggest to write an email to the WAI Interest > Group at w3c-wai-ig@w3.org (archives at [1]). They should be able > to provide a more accurate answer than me :) > > You may also find some resources on their website [2]. > > Regards, > > Denis > > [1] https://lists.w3.org/Archives/Public/w3c-wai-ig/ > [2] https://www.w3.org/WAI/ > > > > On 28/02/2024 18:37, Oliver Odgaard wrote: > > Hi Denis, thanks for the super fast reply. So that means, from reading > > the links you sent, we can still be WCAG 2.1 AA compliant if we use a > > pointer on clickable elements? Is that correct? > > > > -- > > > > > > Kind regards, > > > > *Oliver Odgaard* > > Lead Product Designer > > > > <https://www.mapspeople.com/> > > e. olod@mapspeople.com <mailto:olod@mapspeople.com> > > > > w. mapspeople.com <http://mapspeople.com/> > > > > > > <https://www.linkedin.com/company/mapspeople/> > > <https://www.facebook.com/mapspeople> > > <https://twitter.com/mapspeople?lang=en> > > <https://www.youtube.com/c/MapsPeople/videos> > > > > On 28. feb. 2024 15.19 +0100, Denis Ah-Kang <denis@w3.org>, wrote: > > > Hi Oliver, > > > > > > I'm guessing you are referring to [1] but that issue was actually > > > discussed [2] and the newest version of the spec has the pointer cursor > > > indicating an interactive element [3]. > > > So there's no problem using a pointer on clickable elements. > > > > > > HTH, > > > > > > Denis > > > > > > > > > [1] https://www.w3.org/TR/CSS21/ui.html#cursor-props > > > [2] https://github.com/w3c/csswg-drafts/issues/1936 > > > [3] https://www.w3.org/TR/css-ui-3/#cursor > > > > > > > > > > > > On 28/02/2024 08:50, Oliver Odgaard wrote: > > > > Hi Denis, > > > > > > > > Can you help me regarding use of a pointer on our web application? > > > > > > > > The W3C recommendations says to use a pointer on "The cursor is a > > > > pointer that indicates a link.", but if we choose to use a pointer on > > > > clickable elements like buttons (that aren't links) and interactive > > > > elements inside our product, will that mean we can't say we are not W3C > > > > compliant? > > > > > > > > We would love the added affordance that the pointer adds, making > > > > interactive elements clearly recognizable and usable for all users. > > > > > > > > -- > > > > > > > > > > > > Kind regards, > > > > > > > > *Oliver Odgaard* > > > > Lead Product Designer > > > > > > > > <https://www.mapspeople.com/> > > > > e. olod@mapspeople.com <mailto:olod@mapspeople.com> > > > > > > > > w. mapspeople.com <http://mapspeople.com/> > > > > > > > > > > > > <https://www.linkedin.com/company/mapspeople/> > > > > <https://www.facebook.com/mapspeople> > > > > <https://twitter.com/mapspeople?lang=en> > > > > <https://www.youtube.com/c/MapsPeople/videos> > > > >
Hi there WAI team, Can you help us with this? See thread. ---------- Forwarded message ---------- From: Denis Ah-Kang <denis@w3.org> Date: 28 Feb 2024 at 15.59 +0100 To: Oliver Odgaard <olod@mapspeople.com> Subject: Re: W3C Recommendations Pointer Question > Sorry, I didn't understand you were looking for answers related to > accessibility. I would suggest to write an email to the WAI Interest > Group at w3c-wai-ig@w3.org (archives at [1]). They should be able > to provide a more accurate answer than me :) > > You may also find some resources on their website [2]. > > Regards, > > Denis > > [1] https://lists.w3.org/Archives/Public/w3c-wai-ig/ > [2] https://www.w3.org/WAI/ > > > > On 28/02/2024 18:37, Oliver Odgaard wrote: > > Hi Denis, thanks for the super fast reply. So that means, from reading > > the links you sent, we can still be WCAG 2.1 AA compliant if we use a > > pointer on clickable elements? Is that correct? > > > > -- > > > > > > Kind regards, > > > > *Oliver Odgaard* > > Lead Product Designer > > > > <https://www.mapspeople.com/> > > e. olod@mapspeople.com <mailto:olod@mapspeople.com> > > > > w. mapspeople.com <http://mapspeople.com/> > > > > > > <https://www.linkedin.com/company/mapspeople/> > > <https://www.facebook.com/mapspeople> > > <https://twitter.com/mapspeople?lang=en> > > <https://www.youtube.com/c/MapsPeople/videos> > > > > On 28. feb. 2024 15.19 +0100, Denis Ah-Kang <denis@w3.org>, wrote: > > > Hi Oliver, > > > > > > I'm guessing you are referring to [1] but that issue was actually > > > discussed [2] and the newest version of the spec has the pointer cursor > > > indicating an interactive element [3]. > > > So there's no problem using a pointer on clickable elements. > > > > > > HTH, > > > > > > Denis > > > > > > > > > [1] https://www.w3.org/TR/CSS21/ui.html#cursor-props > > > [2] https://github.com/w3c/csswg-drafts/issues/1936 > > > [3] https://www.w3.org/TR/css-ui-3/#cursor > > > > > > > > > > > > On 28/02/2024 08:50, Oliver Odgaard wrote: > > > > Hi Denis, > > > > > > > > Can you help me regarding use of a pointer on our web application? > > > > > > > > The W3C recommendations says to use a pointer on "The cursor is a > > > > pointer that indicates a link.", but if we choose to use a pointer on > > > > clickable elements like buttons (that aren't links) and interactive > > > > elements inside our product, will that mean we can't say we are not W3C > > > > compliant? > > > > > > > > We would love the added affordance that the pointer adds, making > > > > interactive elements clearly recognizable and usable for all users. > > > > > > > > -- > > > > > > > > > > > > Kind regards, > > > > > > > > *Oliver Odgaard* > > > > Lead Product Designer > > > > > > > > <https://www.mapspeople.com/> > > > > e. olod@mapspeople.com <mailto:olod@mapspeople.com> > > > > > > > > w. mapspeople.com <http://mapspeople.com/> > > > > > > > > > > > > <https://www.linkedin.com/company/mapspeople/> > > > > <https://www.facebook.com/mapspeople> > > > > <https://twitter.com/mapspeople?lang=en> > > > > <https://www.youtube.com/c/MapsPeople/videos> > > > >
Hi there WAI team, Can you help us with this? See thread. ---------- Forwarded message ---------- From: Denis Ah-Kang <denis@w3.org> Date: 28 Feb 2024 at 15.59 +0100 To: Oliver Odgaard <olod@mapspeople.com> Subject: Re: W3C Recommendations Pointer Question > Sorry, I didn't understand you were looking for answers related to > accessibility. I would suggest to write an email to the WAI Interest > Group at w3c-wai-ig@w3.org (archives at [1]). They should be able > to provide a more accurate answer than me :) > > You may also find some resources on their website [2]. > > Regards, > > Denis > > [1] https://lists.w3.org/Archives/Public/w3c-wai-ig/ > [2] https://www.w3.org/WAI/ > > > > On 28/02/2024 18:37, Oliver Odgaard wrote: > > Hi Denis, thanks for the super fast reply. So that means, from reading > > the links you sent, we can still be WCAG 2.1 AA compliant if we use a > > pointer on clickable elements? Is that correct? > > > > -- > > > > > > Kind regards, > > > > *Oliver Odgaard* > > Lead Product Designer > > > > <https://www.mapspeople.com/> > > e. olod@mapspeople.com <mailto:olod@mapspeople.com> > > > > w. mapspeople.com <http://mapspeople.com/> > > > > > > <https://www.linkedin.com/company/mapspeople/> > > <https://www.facebook.com/mapspeople> > > <https://twitter.com/mapspeople?lang=en> > > <https://www.youtube.com/c/MapsPeople/videos> > > > > On 28. feb. 2024 15.19 +0100, Denis Ah-Kang <denis@w3.org>, wrote: > > > Hi Oliver, > > > > > > I'm guessing you are referring to [1] but that issue was actually > > > discussed [2] and the newest version of the spec has the pointer cursor > > > indicating an interactive element [3]. > > > So there's no problem using a pointer on clickable elements. > > > > > > HTH, > > > > > > Denis > > > > > > > > > [1] https://www.w3.org/TR/CSS21/ui.html#cursor-props > > > [2] https://github.com/w3c/csswg-drafts/issues/1936 > > > [3] https://www.w3.org/TR/css-ui-3/#cursor > > > > > > > > > > > > On 28/02/2024 08:50, Oliver Odgaard wrote: > > > > Hi Denis, > > > > > > > > Can you help me regarding use of a pointer on our web application? > > > > > > > > The W3C recommendations says to use a pointer on "The cursor is a > > > > pointer that indicates a link.", but if we choose to use a pointer on > > > > clickable elements like buttons (that aren't links) and interactive > > > > elements inside our product, will that mean we can't say we are not W3C > > > > compliant? > > > > > > > > We would love the added affordance that the pointer adds, making > > > > interactive elements clearly recognizable and usable for all users. > > > > > > > > -- > > > > > > > > > > > > Kind regards, > > > > > > > > *Oliver Odgaard* > > > > Lead Product Designer > > > > > > > > <https://www.mapspeople.com/> > > > > e. olod@mapspeople.com <mailto:olod@mapspeople.com> > > > > > > > > w. mapspeople.com <http://mapspeople.com/> > > > > > > > > > > > > <https://www.linkedin.com/company/mapspeople/> > > > > <https://www.facebook.com/mapspeople> > > > > <https://twitter.com/mapspeople?lang=en> > > > > <https://www.youtube.com/c/MapsPeople/videos> > > > >
Hello When a website has a double input to compare for validation (such as when you are asked to input your email address twice when signing up to a service or filling in a form, to ensure they match) is this considered essential and therefore an exception? You can't paste into the fields so you have to type manually. This particular service is sending a sensitive document, so does this come under 'the information is required to ensure the security of the content' as they are taking care to ensure it's being sent to the correct email address? Thanks Sarah Sent from Outlook for iOS<https://aka.ms/o0ukef>