Mod | Save | ||
---|---|---|---|
STR | 18 | +4 | +4 |
DEX | 14 | +2 | +2 |
CON | 15 | +2 | +2 |
Mod | Save | ||
---|---|---|---|
INT | 11 | +0 | +0 |
WIS | 17 | +3 | +3 |
CHA | 16 | +3 | +3 |
Legendary Resistance (3/Day). If the unicorn fails a saving throw, it can choose to succeed instead.
Magic Resistance. The unicorn has Advantage on saving throws against spells and other magical effects.
Multiattack. The unicorn makes one Hooves attack and one Radiant Horn attack.
Hooves. Melee Attack Roll: +7, reach 5 ft. Hit: 11 (2d6 + 4) Bludgeoning damage.
Radiant Horn. Melee Attack Roll: +7, reach 5 ft. Hit: 9 (1d10 + 4) Radiant damage.
Spellcasting. The unicorn casts one of the following spells, requiring no spell components and using Charisma as the spellcasting ability (spell save DC 14):
At Will: Detect Evil and Good, Druidcraft
1/Day Each: Calm Emotions, Dispel Evil and Good, Entangle, Pass without Trace, Word of Recall
Unicorn’s Blessing (3/Day). The unicorn touches another creature with its horn and casts Cure Wounds or Lesser Restoration on that creature, using the same spellcasting ability as Spellcasting.
Legendary Action Uses: 3. Immediately after another creature’s turn, the unicorn can expend a use to take one of the following actions. The unicorn regains all expended uses at the start of each of its turns.
Charging Horn. The unicorn moves up to half its Speed without provoking Opportunity Attacks, and it makes one Radiant Horn attack.
Shimmering Shield. The unicorn targets itself or one creature it can see within 60 feet of itself. The target gains 10 (3d6) Temporary Hit Points, and its AC increases by 2 until the end of the unicorn’s next turn. The unicorn can’t take this action again until the start of its next turn.
This new design of the stat block has some real accessibility issues, someone here has dropped the ball and not done an accessibility audit.
That's rather ominous. But without more details, I don't think there's necessarily anything for Wizards to do...
are you going to elaborate?
I suppose I could give an example. So you look at the colour contrast on "Large Celestial, Lawful Good" our range of colours to pick from there for text is varied but you're average is #979390 with a background colour of #F5F3EE being consistent. That makes for a contrast ratio of 2.74:1 which is a failure under Success Criterion 1.4.3, even at the largest size would make this a failure. It's one of the very first checks any audit would do, I mean it's the bare basics of any accessibility check. Compare that same section on the older 2014 stat block and you're looking at a ratio of 4.85:1 which is much better. That's just the actual site of the stat block however. The whole DDB site has some accessibility failings.
Missing button elements, lack of basic link text, four different header landmarks. I mean the actual reply button I clicked to send this message fails that same basic contrast check and isn't even keyboard focusable. There's just basic bad html practice too like making a logo image h1? Using headings out of order, multiple h1 instances, so many problems.
couldn't you zoom in or highlight the text though?
Why should somone with an accessibility need be required to when they could have just picked a font colour with a high enough contrast to meet international standards?
why should someone with an accessibility need not have to use tools that would help them access things? i'm not saying they shouldn't as it would be an easy change, but there are still options that would let people who have those needs be able to read the text
Tools work best, when websites are designed properly and not lazily.
im pretty sure the ability to highlight text and zoom in are the exact same for every single website
Then you would be incorrect.
how exactly is highlighting text and zooming in any different than it is on any other website?
Sure we can get into it a little, so the highlight specifically is controlled by the CSS using ::selection. So for example we would be looking for something like:
Now you do need to make sure you're backwards compatible with older browsers like IE by including browser specific CSS:
That is if you're trying to do it site wide, if you wanted to change the highlight styling you just need to drop the above inside that element. P{} for example. Form fields use different elements, input::selection, textarea::selection for example. So it really depends how it has been broken down by component and element.
Zooming is controlled generally using the viewport settings in html, within the meta tag on the header specifically is the most common way. Specifically for this page it is:
<meta name="viewport" content="width=device-width, initial-scale = 1.0, maximum-scale=1.0, user-scalable=no">
It can cause issues if the touch-action in CSS or the wheel event listener in JavaScript are in conflict with html, or any of the three are in conflict really. Could easily disable zoom all together. Which isn't an issue specifically in this case, this website has full zoom functionality.
The point isn't that there's not a number of workarounds, it's that the workarounds should not be needed when companies follow the basic expected standards and have accessibility audits completed. You're also very focused on what you perceive to be a workaround that may work for one person. Poor colour contrast impacts people with a range of needs from obvious visual impairments like low vision, colour blindness or glaucoma but also age decline like macular degeneration or more neurological conditions like dyslexia and ADHD.
Hope that helps explain.
I mean fair enough, and it is something they can easily add to make it more readable for those people, but there are still workarounds, which is really all i'm trying to point out