[3.0.x] Fix a link in the docs (backport #12599) by @mkurz

documentation/manual/releases/release26/migration26/Migration26.md

@@ -300,7 +300,7 @@ Static methods which where already deprecated in 2.5 (e.g. `DynamicForm.form()`)
 
 The [`errors()`](api/java/play/data/Form.html#errors\(\)) method of a [`play.data.Form`](api/java/play/data/Form.html) instance is now deprecated. You should use `allErrors()` instead now which returns a simple `List<ValidationError>` instead of a `Map<String,List<ValidationError>>`. Where before Play 2.6 you called `.errors().get("key")` you can now simply call `.errors("key")`.
 
-From now on, a `validate` method implemented inside a form class (usually used for cross field validation) is part of a class-level constraint. Check out the [[Advanced validation|JavaForms#advanced-validation]] docs for further information on how to use such constraints.
+From now on, a `validate` method implemented inside a form class (usually used for cross field validation) is part of a class-level constraint. Check out the [[Advanced validation|JavaForms#Advanced-validation]] docs for further information on how to use such constraints.
 Existing `validate` methods can easily be migrated by annotating the affected form classes with `@Validate` and, depending on the return type of the validate method, by implementing the [`Validatable`](api/java/play/data/validation/Constraints.Validatable.html) interface with the applicable type argument (all defined in [`play.data.validation.Constraints`](api/java/play/data/validation/Constraints.html)):
 
 | **Return type**                                                                    | **Interface to implement**

documentation/manual/releases/release27/migration27/Migration27.md

@@ -318,7 +318,7 @@ By default, routers are unprefixed, so this will only cause a change in behavior
 ### All Java form `validate` methods need to be migrated to class-level constraints
 
 The "old" `validate` methods of a Java form will not be executed anymore.
-Like announced in the [[Play 2.6 Migration Guide|Migration26#Java-Form-Changes]] you have to migrate such `validate` methods to [[class-level constraints|JavaForms#advanced-validation]].
+Like announced in the [[Play 2.6 Migration Guide|Migration26#Java-Form-Changes]] you have to migrate such `validate` methods to [[class-level constraints|JavaForms#Advanced-validation]].
 
 > **Important**: When upgrading to Play 2.7 you will not see any compiler warnings indicating that you have to migrate your `validate` methods (because Play executed them via reflection).
 

documentation/manual/working/javaGuide/main/forms/JavaForms.md

@@ -49,7 +49,7 @@ You can define additional constraints that will be checked during the binding ph
 
 > **Tip:** The `play.data.validation.Constraints` class contains several built-in validation annotations. All of these constraint annotations are defined as `@Repeatable`. This lets you, for example, reuse the same annotation on the same element several times but each time with different `groups`. For some constraints however it makes sense to let them repeat itself anyway, like `@ValidateWith`/`@ValidatePayloadWith` for example.
 
-In the [Advanced validation](#advanced-validation) section further below you will learn how to handle concerns like cross field validation, partial form validation or how to make use of injected components (e.g. to access a database) during validation.
+In the [Advanced validation](#Advanced-validation) section further below you will learn how to handle concerns like cross field validation, partial form validation or how to make use of injected components (e.g. to access a database) during validation.
 
 ## Handling binding failure